Oracle native sequencing: nextVal executed two times.

Question

We are migrating from Weblogic 6.1 sp 5 & TopLink 3.6.3 to Weblogic 8.1 sp 2 & TopLink 9.0.4 and we are having this issue:
It seems that when assigning the sequence to new objets TopLink execs the nextVal for the sequence twice. In fact we probably wouldn't notticed it if it was just that, the problem is that TopLink seems to register the object into the cache with an oid and assigning the next one to the object stored in the database so we are getting NoSuchObjectException each time we try to access them.
Here is a dump of TopLink's log showing the problem:
[TopLink]: ServerSession(22807116)--Connection(0)--client acquired
[TopLink]: ClientSession(25858791)--Connection(0)--acquire unit of work: 10772417
[TopLink]: UnitOfWork(10772417)--Connection(0)--JTS register
[TopLink]: ServerSession(22807116)--Connection(17740413)--SELECT SEQ_BOOK.NEXTVAL FROM DUAL
[TopLink]: ServerSession(22807116)--Connection(17558511)--SELECT SEQ_PAGE.NEXTVAL FROM DUAL
[TopLink]: UnitOfWork(10772417)--Connection(0)--Before JTS Completion
[TopLink]: UnitOfWork(10772417)--Connection(25919386)--Begin batch statements
[TopLink]: UnitOfWork(10772417)--Connection(25919386)--INSERT INTO AUTHOR (NAME, OCA, OID) VALUES (?, ?, ?)
[TopLink]: UnitOfWork(10772417)--Connection(0)-- bind => [Roger Penrose, 2004-05-11 18:54:01.917, 442803]
[TopLink]: UnitOfWork(10772417)--Connection(25919386)--End Batch Statements
[TopLink]: ClientSession(25858791)--Connection(25919386)--Begin batch statements
[TopLink]: ClientSession(25858791)--Connection(25919386)--INSERT INTO BOOK (NAME, OCA, OID, OID_AUTHOR) VALUES (?, ?, ?, ?)
[TopLink]: ClientSession(25858791)--Connection(0)-- bind => [The Emperor's New Mind, 2004-05-11 18:54:01.92, 347404, 442803]
[TopLink]: ClientSession(25858791)--Connection(0)-- bind => [Shadows of the Mind, 2004-05-11 18:54:01.943, 347405, 442803]
[TopLink]: ClientSession(25858791)--Connection(25919386)--End Batch Statements
[TopLink]: UnitOfWork(10772417)--Connection(0)--After JTS Completion
[TopLink]: UnitOfWork(10772417)--Connection(0)--release unit of work
[TopLink]: ClientSession(25858791)--Connection(0)--client released
[TopLink]: ServerSession(22807116)--Connection(0)--client acquired
[TopLink]: ClientSession(116689)--Connection(0)--acquire unit of work: 32580168
[TopLink]: UnitOfWork(32580168)--Connection(0)--JTS register
[TopLink]: UnitOfWork(32580168)--Connection(0)--Before JTS Completion
[TopLink]: UnitOfWork(32580168)--Connection(17129104)--Begin batch statements
[TopLink]: UnitOfWork(32580168)--Connection(17129104)--INSERT INTO AUTHOR (NAME, OCA, OID) VALUES (?, ?, ?)
[TopLink]: UnitOfWork(32580168)--Connection(0)-- bind => [Benoit Mandelbrot, 2004-05-11 18:54:49.264, 442805]
[TopLink]: UnitOfWork(32580168)--Connection(17129104)--End Batch Statements
[TopLink]: ClientSession(116689)--Connection(17129104)--Begin batch statements
[TopLink]: ClientSession(116689)--Connection(17129104)--INSERT INTO BOOK (NAME, OCA, OID, OID_AUTHOR) VALUES (?, ?, ?, ?)
[TopLink]: ClientSession(116689)--Connection(0)-- bind => [Les objets fractals, forme, hasard et dimension, 2004-05-11 18:54:49.266, 347409, 442805]
[TopLink]: ClientSession(116689)--Connection(0)-- bind => [The Fractal Geometry of Nature, 2004-05-11 18:54:49.282, 347408, 442805]
[TopLink]: ClientSession(116689)--Connection(17129104)--End Batch Statements
[TopLink]: UnitOfWork(32580168)--Connection(0)--After JTS Completion
[TopLink]: UnitOfWork(32580168)--Connection(0)--release unit of work
[TopLink]: ClientSession(116689)--Connection(0)--client released
the test is about creating two objects (well, we are actually creating 6 objects in this sample as we are creating two "master" objects and adding two related (in a one to many relationship) objects to each one.)
The thing I would like you to notice is this:
The first AUTHOR object gets assigned the OID 442803 wether the next AUTHOR object gets the OID 442805 although we expected it to be 442804.
The same occurs with the objects in the "many" side of the relation. They get sibiling OIDs but with a gap of two OIDs when creating the last two.
I have been searching for simmilar problems in this forums and I found two posts:
Both where related to a bug of an older version of TopLink (9.0.3 I think) when using something different than a number for the sequence field of an object. I expect it to be fixed in 9.0.4 version as it seemed to be fixed even for the 9.0.3 version. May it be a regression bug?
Anyway, we are using BigDecimal on entity bean's sequence number and IIRC NUMBER(18) in Oracle tables.
Currently our TopLink version is: 9.0.4 (031126)
Our native sequence has an allocation size of 200 and it matches with SEQUENCEs defined in Oracle.
As we are migratting from TopLink 3.6.3 and we have not changed the sequence prealocation size (we have not touched the database at all) we don't expect the problem to be on sequence prealocation.
I must say we have changed the "default" JDBC driver that TopLink uses when doing the issuing the loging phase (which I think is a SUN driver) to an oracle.jdbc.driver.OracleDriver as we were having problems with timestamp locking.
Any idea?
Thanks in advance.
Ignacio.

Answer 1

Solved!
It was my fault. I was doing a really nasty thing to the entity beans.
I must publicly thank my work mate (which is a pretty smart girl, I must say) in tracking down this issue.
Here is what (we think) was happening:
As I told in previous post in this post we are in the process of moving from TopLink 3.6.3 (EJB 1.1) to TopLink 9.0.4 (EJB 2.0). We do have a "super class" in our application where we had some common things of our entity beans, i.e. entityContext, oid and oca attributes. We have also some methods that retrieve and set values from and to the entity beans via value objects (in order to avoid the heavy RMI operations when doing it through "standard" getters and setters) well, it happened that the current implementation of the "batch setting" method used the getDeclaringMethods to update in both UPDATE and INSERT opperations entity attributes with the data of the value object.
When switching to EJB 2.0 we had to push down both the oid and oca attributes (in order of being able do deploy them) to each final entity bean and now they where being included in the setting process!
You can imagine an scenario like this:
1. ejbCreate() // TopLink issues the SELECT SEQ_XXX NEXT VAL FROM DUAL and sets the oid of the EJB
2. setAttributes() // transfer info from the value object to the newly created EJB: including a setOid(null)!
3. commit() (Before Completion)
4. TopLink detects that the damm object surprisingly DOES NOT have the oid attribute setted so it performs another SELECT SEQ_XXX NEXT VAL FROM DUAL in order to "fix" this big problem.
5. commit() (After Completion) // the object is written to the database with the second value from the sequence whereas the first value is used to identify the entity bean into the identity cache.
Well it may not be "exactly" what is happening but I'm sure we are not so far from reality with our assumptions.
Andrei Ilitchev, thanks for your interest, sorry I could not post this sooner.