aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piergiuseppe Spinelli (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ARIES-1767) TransactionControl new transaction isolation among thread
Date Sat, 23 Dec 2017 20:06:00 GMT

     [ https://issues.apache.org/jira/browse/ARIES-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Piergiuseppe Spinelli updated ARIES-1767:
-----------------------------------------
    Description: 
Hi,

I'm evaluating the usage of some enterprise features with Karaf.

I wrote a test shell command (attached) in order to check the behavior of TransactionControl
in a multi-threaded environment. 

I read tx-control is Thread Safe, so I wrote the command code for check isolation of new transactions
created for different threads starting by the same injected TransactionControl service.

Now, it is not working as it was intended to. Maybe for my misunderstanding about its usage.

However:
- I use this simple table:
CREATE TABLE `long_term_stata` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `VERSION` bigint(20) DEFAULT NULL,
  `STATUS` varchar(255) NOT NULL,
  `PROCESSO` varchar(255) NOT NULL,
  `TARGET` varchar(255) NOT NULL,
  `NOTE` varchar(255) DEFAULT NULL,
  `EXTRA_INFO` longblob,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `PROCESSO_UNIQUE` (`PROCESSO`)
) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;

The command runs N thread performing in a new transaction a "select ... for update" on the
same row, a read of a status, its increment and at the and an updateRow.

I believed the first Thread kept a row write lock and the other ones waited each one to acquire
the row lock until the end of their own transaction. So at the end the counter in the STATUS
field of the table should have been equals to N (the number of threads).

Instead the threads seem to be executed in parallel randomically so that the order of read
& write operations is not respected, ending with a STATUS < N.

If I set the ROW LOCK from another client is seems to work as waited. In MySqlWorkbench:
start transaction;
SELECT * FROM long_term_stata where id=19 for update;

The command waits trying to acquire the row lock until I type a COMMIT in the workbench.

So, my conclusion (but easily I made some mistake) is that the transaction isolation does
not work properly among threads starting transactions from the same instance of injected TransactionControl.

Could you help me confirming if it is a strange behavior or advising for the right way to
write the test?

Thanks in advance

  was:
Hi,

I'm evaluating the usage of some enterprise features with Karaf.

I wrote a test shell command (attached) in order to check the behavior of TransactionControl
in a multi-threaded environment. 

I read tx-control is Thread Safe, so I wrote the command code for check isolation of new transactions
created for different threads starting by the same injected TransactionControl service.

Now, it is not working as it was intended to. Maybe for my misunderstanding about its usage.

However:
- I use this simple table:
CREATE TABLE `long_term_stata` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `VERSION` bigint(20) DEFAULT NULL,
  `STATUS` varchar(255) NOT NULL,
  `PROCESSO` varchar(255) NOT NULL,
  `TARGET` varchar(255) NOT NULL,
  `NOTE` varchar(255) DEFAULT NULL,
  `EXTRA_INFO` longblob,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `PROCESSO_UNIQUE` (`PROCESSO`)
) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;

The command runs N thread performing in a new transaction a "select ... for update" on the
same row, a read of a status, its increment and at the and an updateRow.

I believed the first Thread kept a row write lock and the other ones waited each one to acquire
the row lock until the end of their own transaction. So at the end the counter in the STATUS
field of the table should have been equals to N (the number of threads).

Instead the threads seem to be executed in parallel randomically so that the order of read
& write operations is not respected, ending with a STATUS < N.

If I set the ROW LOCK from another client is seems to work as waited. In MySqlWorkbench:
start transaction;
SELECT * FROM long_term_stata where id=19 for update;

The command waits trying to acquire the row lock until I type a COMMIT in the workbench.

So, my conclusion (but easily I have done some mistake) is that the transaction isolation
does not work properly among threads starting transactions from the same instance of injected
TransactionControl.

Could you help me confirming if it is a strange behavior or advising for the right way to
write the test?

Thanks in advance


> TransactionControl new transaction isolation among thread
> ---------------------------------------------------------
>
>                 Key: ARIES-1767
>                 URL: https://issues.apache.org/jira/browse/ARIES-1767
>             Project: Aries
>          Issue Type: Bug
>          Components: tx-control
>    Affects Versions: tx-control-0.0.3
>         Environment: Karaf 4.2.0.M1, MySql Community Server 5.6.19, Windows 10
>            Reporter: Piergiuseppe Spinelli
>         Attachments: TestTXCommand.java
>
>
> Hi,
> I'm evaluating the usage of some enterprise features with Karaf.
> I wrote a test shell command (attached) in order to check the behavior of TransactionControl
in a multi-threaded environment. 
> I read tx-control is Thread Safe, so I wrote the command code for check isolation of
new transactions created for different threads starting by the same injected TransactionControl
service.
> Now, it is not working as it was intended to. Maybe for my misunderstanding about its
usage.
> However:
> - I use this simple table:
> CREATE TABLE `long_term_stata` (
>   `ID` bigint(20) NOT NULL AUTO_INCREMENT,
>   `VERSION` bigint(20) DEFAULT NULL,
>   `STATUS` varchar(255) NOT NULL,
>   `PROCESSO` varchar(255) NOT NULL,
>   `TARGET` varchar(255) NOT NULL,
>   `NOTE` varchar(255) DEFAULT NULL,
>   `EXTRA_INFO` longblob,
>   PRIMARY KEY (`ID`),
>   UNIQUE KEY `PROCESSO_UNIQUE` (`PROCESSO`)
> ) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;
> The command runs N thread performing in a new transaction a "select ... for update" on
the same row, a read of a status, its increment and at the and an updateRow.
> I believed the first Thread kept a row write lock and the other ones waited each one
to acquire the row lock until the end of their own transaction. So at the end the counter
in the STATUS field of the table should have been equals to N (the number of threads).
> Instead the threads seem to be executed in parallel randomically so that the order of
read & write operations is not respected, ending with a STATUS < N.
> If I set the ROW LOCK from another client is seems to work as waited. In MySqlWorkbench:
> start transaction;
> SELECT * FROM long_term_stata where id=19 for update;
> The command waits trying to acquire the row lock until I type a COMMIT in the workbench.
> So, my conclusion (but easily I made some mistake) is that the transaction isolation
does not work properly among threads starting transactions from the same instance of injected
TransactionControl.
> Could you help me confirming if it is a strange behavior or advising for the right way
to write the test?
> Thanks in advance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message