You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Dallas Hopewell (JIRA)" <ji...@apache.org> on 2013/07/15 13:06:54 UTC

[jira] [Commented] (OPENJPA-2395) Using ids with GenerationType.SEQUENCE is causing an implicit commit with hsqldb and oracle

    [ https://issues.apache.org/jira/browse/OPENJPA-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708387#comment-13708387 ] 

Dallas Hopewell commented on OPENJPA-2395:
------------------------------------------

I found the same problem (I am using Oracle), I worked around it by overriding the "nativeSequenceType" setting on the DBDictionary.

<property name="openjpa.jdbc.DBDictionary" value="oracle(NativeSequenceType=1)"/>

This sets the DBDictionary.nativeSequenceType parameter to Seq.TYPE_NONTRANSACTIONAL instead of the default from the DBDictionary class which is Seq.TYPE_CONTIGUOUS and then OpenJPA alters the sequence on a separate connection.
                
> Using ids with GenerationType.SEQUENCE is causing an implicit commit with hsqldb and oracle
> -------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-2395
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2395
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc, kernel
>    Affects Versions: 2.2.2
>            Reporter: Vijaya Gorla
>
> @Entity
> public class Account {
>   @Id
>   @SequenceGenerator(name = "ACCOUNT_ID_SEQ", sequenceName = "ACCOUNT_ID_SEQ")
>   @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "ACCOUNT_ID_SEQ")
>   private Long accountId;
> ....
> This mapping is causing an alter sequence statement to be issued when an Account entity is flushed for the first time since the container start up. 
> If I persist an account entity and an organisation entity in a single transaction, here is the sequence of SQL statements issued:
> 1. ALTER SEQUENCE TESTSCHEMA.ACCOUNT_ID_SEQ INCREMENT BY 50; // Implicit commit
> 2. SELECT TESTSCHEMA.ACCOUNT_ID_SEQ.NEXTVAL FROM DUAL;
> 3. INSERT INTO TESTSCHEMA.ACCOUNT (ACCOUNT_ID, UUID) VALUES (?, ?);
> 4. ALTER SEQUENCE TESTSCHEMA.ORG_ID_SEQ INCREMENT BY 50; // Implicit commit
> 5. SELECT TESTSCHEMA.ORG_ID_SEQ.NEXTVAL FROM DUAL;
> 6. INSERT INTO TESTSCHEMA.ORGANISATION (ORG_ID, ORG_NAME, ACCOUNT_ID)  VALUES (?, ?, ?);
> If the transaction then rolls back because of an unrelated issue, you would expect that the both inserts would be rolled back. However, Oracle is issuing an implicit commit at statement 4 because it is a DDL statement, resulting in a partial commit scenario. (Account committed, Organisation rolled back)
> I have narrowed it down to org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.allocateInternal method. Surely this is not the intended behaviour.

--
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