Scott Parkerson created OPENJPA-2419:
----------------------------------------
Summary: Sequence Caching Attempt Failing in JTA Managed
Environments with PostgreSQL
Key: OPENJPA-2419
URL: https://issues.apache.org/jira/browse/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 fix:
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: http://www.atlassian.com/software/jira
