openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Parkerson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OPENJPA-2196) Create Sequence Postgres 9.1
Date Fri, 29 Jun 2012 18:04:44 GMT

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

Scott Parkerson commented on OPENJPA-2196:
------------------------------------------

Consider, also, this scenario, where OpenJPA is using PostgreSQL and the owner of sequence
is not the same user of the client (but client does have the {{USAGE}} grant on the sequence
to call nextval, etc.). Let i be the initial starting value of the database sequence.

1. An OpenJPA application connects to the database, and inserts n records into the database
where n > 1 and n < allocationSize. On the first insert, the {{ALTER SEQUENCE}} call
is made fails silently (although PostgreSQL will log an error serverside, but since the exception
is swallowed by the client, no one is the wiser -- including the code that "thinks" it has
the next allocationSize ids cached. The database, however, still thinks that next sequence
number is i+1.

2. If the application is stopped and restarted, the next insert will fail due to a duplicate
key violation (because, since the first ALTER SEQUENCE failed, the database still thinks its
current sequence is i+1, but OpenJPA allowed that record to be inserted in the first run.

I'm not seeing the behavior where the ALTER SEQUENCE call marks the transaction for rollback,
though. I *think* I'm in a JTA-managed transaction, too... so not sure about that. Looking
at the code in NativeJDBCSeq.allocateInternal, it appears that a new connection is grabbed
from the store; not sure that connection is under JTA.

At minimum, I think that OpenJPA should detect the failure to ALTER SEQUENCE and not cache
allocationSize values (perhaps logging to WARN level the first time this happens per session
per sequence). Additionally, the original DBDictionary.commonCreateAlterSequenceSQL should
always specify INCREMENT BY even if it is set to 1, as that breaks the "workaround" for users
who wish emulate previous OpenJPA behavior using useNativeSequenceCache=False.

                
> Create Sequence Postgres 9.1
> ----------------------------
>
>                 Key: OPENJPA-2196
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2196
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc, jpa
>    Affects Versions: 2.2.0
>         Environment: OpenJPA-2.2.0
> Transaction-type JTA
> Postgres 9.1
> JBoss 6.1
>            Reporter: Hendi Marcos Ramos Silva
>            Assignee: Albert Lee
>             Fix For: 2.2.1
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Sorry my bad english ..
> when annotated a entity with @SequenceGenerator and with allocationSize = 1 and initialValue
= 1, the method DBDictionary.commonCreateAlterSequenceSQL is creating a alter sequence sql
invalid for Postgres 9.1.
> Despite the documentation of postgres inform you that the other parameters are optional
(http://www.postgresql.org/docs/9.1/static/sql-altersequence.html), an error occurs in executing
the sql below.
> Eg: ALTER SEQUENCE schema_experimento.usuario_sq (no other attributes)
> Even the method NativeJDBCSeq.udpateSql being fault tolerant, the connection is marked
for rollback and not allowing run the next val of sequence.
> HĂȘndi Marcos

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message