[
https://issues.apache.org/jira/browse/OPENJPA-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Zowalla resolved OPENJPA-2419.
--------------------------------------
Resolution: Fixed
Already fixed on master: NativeJDBCSeq.allocateInternal runs ALTER SEQUENCE on
getConnection(store, true), which AbstractJDBCSeq.getConnection:173-183 takes
from getDataSource2 (non-JTA) and commits separately (c5b97348f, on master);
disableAlterSeqenceIncrementBy (4e8732d4a) also on master. Closing; please
reopen if this still happens with OpenJPA 4.x.
> 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
> Priority: Major
>
> 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 was sent by Atlassian Jira
(v10.3.26#10030026)
