Weblogic Eclipselink Sequence Table Connection Pool Sequence Separate transaction while JTA on main transaction

Question

Hi,
And thanks in advance for your support.
In weblogic 12, managing to get the eclipse link connection sequencing mechanism when one uses Tables for sequencing entity ids seems to be complicated.
QUICK REFERENCE:
http://www.eclipse.org/eclipselink/api/2.5/org/eclipse/persistence/config/PersistenceUnitProperties.html
The concept:
While having EJB, MDBs etc... run on a JEE container, be it glassfish or weblogic, it should be possible to have the main thread transaction be managed as part of JTA global transactions by the contianer.
Namely, pumping messages to JMS queues, persisting entities etc.
Meanwhile, it should be also possible to as the transaction is on going write and update entity ids from sequencing tables.
For this very purpose, eclipse link provides persistence.xml properties, such as the now deprecated eclipselink.jdbc.sequence-connection-pool" value="true", to fullfill this very purpose.
This option greatly avoids dead longs, by allowing eclipse link to fetch a non JTA managed connection, pseudo "two phase locking read table update table" go to the datbase and fetch a new sequence.
The same mechnism under JTA is a disaster. A transaction that creates ten different entities, might do ten reads and updates on this table, while mean while a competing transaction might be trying to do the same. It is guaranteed dead lock with minimal stress on the environment.
Under glassfish, for example, tagging a persistence.xml with :
<persistence-unit name="MY_PU" transaction-type="JTA">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <jta-data-source>jdbc/DERBY_DS</jta-data-source>
        <non-jta-data-source>jdbc/DERBY_DS</non-jta-data-source>       
        <properties>           
            <property name="eclipselink.jdbc.sequence-connection-pool" value="true" />
        </properties>
</peristence-unit>
does miracles, when entities are using TABLE sequencing.
Under weblogic, say you are using the Derby embedded XA driver with two phase commit, deploying the applicaiton immediately leads to:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.3.v20120629-r11760): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Cannot call commit when using distributed transactions
Error Code: 0
  at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:324)
  at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicCommitTransaction(DatabaseAccessor.java:426)
  at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.commitTransaction(DatasourceAccessor.java:389)
  at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.commitTransaction(DatabaseAccessor.java:409)
  at org.eclipse.persistence.internal.sequencing.SequencingManager$Preallocation_Transaction_Accessor_State.getNextValue(SequencingManager.java:579)
  at org.eclipse.persistence.internal.sequencing.SequencingManager.getNextValue(SequencingManager.java:1067)
  at org.eclipse.persistence.internal.sequencing.ClientSessionSequencing.getNextValue(ClientSessionSequencing.java:70)
  at org.eclipse.persi
While weblogic is right that their might be a distributed transaction ongoing, it is mistaken in the fact tha tthe connection requested by eclipse link for generating the ID should be part of the global transaciton.
Eclipse link provides other ways to attempt to configure the sequencing mechanism, by sating for example a non-jta transaction.
I have attempted also using these properties both withe original data DERBY_DS that uses the XA driver, and later with a new data source i created on purpose to try to work around the sequencing contengy.
For example:
<!--property name="eclipselink.jdbc.sequence-connection-pool.nonJtaDataSource" value="jdbc/DERBY_SEQUENCING_NON_JTA" /-->
            <!--property name="eclipselink.connection-pool.sequence.nonJtaDataSource" value="jdbc/DERBY_SEQUENCING_NON_JTA" /-->
This new DERBY_SEQUENCING_NON_JTA is explicitly configured to use a NON_XA driver with global transactions flag set to disabled.
Regardless, the only thing I get out of this is that the application is deployed and super fast, up to the point where i stress it with a system test that introduces some degreee of concurrency, and then I see the dead locks on the sequencing table.
Meaning that the ongoing transactions are holding tight to their locks on the sequencing table.
Is this a known issue?
Is there something I am missing in the configuration?
It really should not be this diffcult to get eclipse link to run its sequence reads and updates on a separate transaction of the main JTA transaction, but so far looks impossible.
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.3.v20120629-r11760): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
Error Code: 30000
Call: UPDATE ID_GEN SET SEQ_VALUE = SEQ_VALUE + ? WHERE SEQ_NAME = ?
  bind => [2 parameters bound]
Query: DataModifyQuery(name="MyEntity_Gen" sql="UPDATE ID_GEN SET SEQ_VALUE = SEQ_VALUE + ? WHERE SEQ_NAME = ?")
Many thanks for your help.

Answer 1

Are you calling the cmp bean code and your new Sql code under a same transactional context?
The following setting
"rollbackLocalTxUponConnClose=true"
will make the connectionpool to call the rollback method on the connection object before keeping it back in the pool. In your sql code if you are calling connection.close() , then your entire transaction will be rolled back.
CMP bean requires a transactional connection while communicating with the database.
What is the sequence of code execution?
I think you must be calling sql code first and then cmp bean code later.
You may avoid this problem in this way. This is my guess based on my understanding on your code execution.
1. set rollbackLocalTxUponConnClose=false
Execute the sql code and cmp code in a single transaction (in a single session bean method with cmt or bmt transaction ). Specify tx.rollback if it is bmt. or call tx.setRollbackOnly() if it is a cmt. In this way you will have control to roll back the transactions.
Hope this helps you.
bmt-> bean managed transaction
cmt-> container managed transaction.
Regards,
Seshi.