There shouldn't be any real magic to this, it should "just work".
It should based both on the nature of sequences, and how they're used in GF.
If it's a simple sequence with a allocation size of 1, I can't see this happening at all, assuming all transactions commit. if there are transcations that are rolling back, yet somehow the sequence numbers are escaping, I can see this happening.
If transactions are being rolled back, then corrupted objects, including "new" objects with IDs set can remain behind. But those ID's may not have been committed to the DB, so it's possible to have an ID that's not in the DB. If you try and save that object again (with the now bogus ID), it's possible some other correct transaction has managed to consume the ID you have already, and that would cause the error.
I don't recall if Oracle will commit a sequence regardless of the transaction status (i.e. if you do nextval('sequence') will that "stick" if the transaction is rolled back).
If this is happening without rollbacks being involved, then I don't know. But that's the only way I can see this really occurring.
Recall, that the basic rule is that if you have an object that was used in a JPA transaction that was rolled back, you best throw that object away and create/fetch a fresh one, as any objects involved in the rolledback transaction are in an inconsistent state.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=240219