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.