openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Parkerson (JIRA)" <>
Subject [jira] [Created] (OPENJPA-2419) Sequence Caching Attempt Failing in JTA Managed Environments with PostgreSQL
Date Tue, 06 Aug 2013 23:23:48 GMT
Scott Parkerson created OPENJPA-2419:

             Summary: Sequence Caching Attempt Failing in JTA Managed Environments with PostgreSQL
                 Key: OPENJPA-2419
             Project: OpenJPA
          Issue Type: Bug
          Components: jdbc
    Affects Versions: 2.2.2
         Environment: Fuse (JBoss) ESB 6.0.0-redhat-024 (Karaf 2.3.0)
OpenJPA 2.2.2
Apache Aries 1.0.0 (JPA/JTA/JNDI/Blueprint)
            Reporter: Scott Parkerson

About a year ago, there was a bug (OPENJPA-2196) that I contributed a patch to that deals
with cases where OpenJPA's sequence caching cannot be used if the native sequence in the database
is not owned by the role connecting to the database. This patch was included in OpenJPA 2.2.2.

Since then, I've started using JTA-managed transactions in my container (the container being
JBoss Fuse ESB, using Aries JPA/JNDI/JTA), and have hit the following snags with my previous

1. When the attempt to ALTER SEQUENCE ... INCREMENT BY fails, it basically hoses the entire
transaction, causing the next thing (which is to get the next value in the sequence) to fail
because the transaction is now invalid and must be rolled back.

2. Trying to work around this using either ConnectionFactory2Name or the non-jta-data-source
configuration items in my persistence.xml file seems to never matter, as ALL native sequences
in OpenJPA are of type TYPE_CONTIGUOUS, and thus it will always choose the managed (jta-data-source
or ConnectionFactoryName) methods to attempt to modify the sequence. I cannot see where it
attempts to suspend the transaction, either.

Perhaps there is a workaround, but I cannot see it. Does anyone else have any ideas on what
could be done to make this work?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message