I have an application getting a failure when servicing identical requests simultaneously. Both threads follow the same use case at the same time. The scenario is this:
1. ThreadA and ThreadB both query a user table (using a DAO with JDBC) to check the existence of a username. The username is not present, so both queries return false.
2. Both threads create an entity bean mapped to the user table, both using the same user name.
3. ThreadA commits fine, while ThreadB throws an exception, since although the username field is not the PK, there is a unique index on that column in the database.
All steps are handled within the scope of a single JTA transaction.
When the requests are spaced out rather than sent simultaneously, the application works as expected (ThreadB finds the username already present and acts accordingly). Additionally, it happens on some hardware (faster) and not others.
I'm guessing that I can avoid this unpleasantness by reeplacing the DAO JDBC select with an entity bean finder method, and ThreadB's lookup will find the entity instance in cache (although uncommitted to the DB) and handle as though the record exists, but I am wondering if there is a setting I can change with regard to the transaction behavior.
Hi Art, well since the problem is caused by a select followed by an INSERT, i belive the transactional scientific term for it would be that u've got a "phantom read" problem on your head, and the only way to get rid of phantoms is serialization of the transactions.
U need to call setTransactionIsolation(TRANSACTION_SERIALIZABLE) on jdbc