[
https://issues.apache.org/jira/browse/ARIES-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piergiuseppe Spinelli updated ARIES-1767:
-----------------------------------------
Summary: TransactionControl and transaction isolation among thread (was:
TransactionControl new transaction isolation among thread)
> TransactionControl and 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)
