EJB transaction isolation not working

Question

I'm trying to use TRANSACTION_SERIALIZABLE isolation level in my EJB test application
with no success so far.
The environment is Windows NT, WebLogic 6.1, Informix DB (which, according to
its documentation, supports TRANSACTION_SERIALIZABLE), and a Tx Data Source on
a JDBC pool.
I have an CMP Entity EJB with the following definitions:
<container-transaction>
<method>
<ejb-name>SdrFA</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<transaction-isolation>
<isolation-level>TRANSACTION_SERIALIZABLE</isolation-level>
<method>
<ejb-name>SdrFA</ejb-name>
<method-intf>Home</method-intf>
<method-name>*</method-name>
</method>
<method>
<ejb-name>SdrFA</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
</transaction-isolation>
The entity EJB is used by a servlet that uses JTA to establish a transaction that
the EJB methods should share ("Required" transaction attribute). The servlet is
as follows:
// Establish a transaction
UserTransaction trn =
(UserTransaction) ctx.lookup("java:comp/UserTransaction");
trn.begin();
trn.setTransactionTimeout(20);
// Get the EJB
SdrFA fFA = home.findByPrimaryKey( fFAPK );
// Update an attribute
fFA.setSomeAtt("someData");
// Sleep to control concurrency
Thread.currentThread().sleep(t * 1000);
// commit
trn.commit();
I expected this setup to prevent concurrent updates and even accesses to the same
DB table row, but this is not the case: when I invoke the servlet from a session
and then invoke it again from another session while the first one is sleeping,
the second one completes all right and is visible in the DB before the first one
commits.
Just in case TRANSACTION_SERIALIZABLE is not supported after all, I tried TRANSACTION_REPEATABLE_READ
instead whith the same results.
Is there something I'm missing, or any error in my setup?
Thanks for any suggestion,
Pere Torrodellas

Answer 1

Hi Pere,
AFAIR delay-updates-until-end-of-tx is set to True by default, so the
actual update is not issued untill TX is commited. I'd try setting it to
false and running the test again.
Here are some documentation references:
http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1048164
http://e-docs.bea.com/wls/docs61/ConsoleHelp/wls_ejb_jar_dtd.html
Regards,
Slava Imeshev
"Pere Torrodellas" <[email protected]> wrote in message
news:[email protected]...
>
I'm trying to use TRANSACTION_SERIALIZABLE isolation level in my EJB testapplication
with no success so far.
The environment is Windows NT, WebLogic 6.1, Informix DB (which, accordingto
its documentation, supports TRANSACTION_SERIALIZABLE), and a Tx DataSource on
a JDBC pool.
I have an CMP Entity EJB with the following definitions:
<container-transaction>
<method>
<ejb-name>SdrFA</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<transaction-isolation>
<isolation-level>TRANSACTION_SERIALIZABLE</isolation-level>
<method>
<ejb-name>SdrFA</ejb-name>
<method-intf>Home</method-intf>
<method-name>*</method-name>
</method>
<method>
<ejb-name>SdrFA</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
</transaction-isolation>
The entity EJB is used by a servlet that uses JTA to establish atransaction that
the EJB methods should share ("Required" transaction attribute). Theservlet is
as follows:
// Establish a transaction
UserTransaction trn =
(UserTransaction) ctx.lookup("java:comp/UserTransaction");
trn.begin();
trn.setTransactionTimeout(20);
// Get the EJB
SdrFA fFA = home.findByPrimaryKey( fFAPK );
// Update an attribute
fFA.setSomeAtt("someData");
// Sleep to control concurrency
Thread.currentThread().sleep(t * 1000);
// commit
trn.commit();
I expected this setup to prevent concurrent updates and even accesses tothe same
DB table row, but this is not the case: when I invoke the servlet from asession
and then invoke it again from another session while the first one issleeping,
the second one completes all right and is visible in the DB before thefirst one
commits.
Just in case TRANSACTION_SERIALIZABLE is not supported after all, I triedTRANSACTION_REPEATABLE_READ
instead whith the same results.
Is there something I'm missing, or any error in my setup?
Thanks for any suggestion,
Pere Torrodellas