Here is another interesting situation that is confusing me.
If I use the CMP2.x Container, but enable OptimisticLocking, each update does a very complex WHERE clause to match the original data. For example, to change a tuple from (A,B,C) to (A,B,D), the CMP engine creates an SQL:
UPDATE foobar SET first=A,second=B,third=D WHERE
first=A, second = B, third = C.
That is fine, IF the types are simple types(String, ints). The CMP engines has a few issues with booleans(jdbc bit), nullables, dates.
I created a row with a PK=3 and set its data(within a single transaction) and it failed because it couldn't find the row that this transaction originally created. I can see the insert of (3,null,null,null,null, etc). And the update of (3,"foo","bar","sept 15") WHERE (3,null,null,null,null). I don't understand why this final query didn't find the row it originally created?
Anyone know why?
what database are u using? did u try doing a sql query to see if the records are infact null?
BTW, do u have a testcase i can try here on my machine ?
> what database are u using?
> did u try doing a sql query to see if the records are infact null?
Hmm.. well, the only insert I see is the insert during the ejbCreate stage. I haven't done an insert but can only assume it exists during the transaction. If I change to NoLock, then the where clause is based on the PK and is successful during the update.
>>BTW, do u have a testcase i can try here on my machine ?
test machines are at work, i'll post again tomorrow...
A coworker found this issue:
Its title is
Summary: Optimistic Locking Problem with v.3.2.1
All updates fail if any locked field has been intialized with
null as its value.
I'm cool with issue now(rather I know its been noted), I'm still confused with my original problem.
After even more looking, I found a similar case:
Nice to know I'm not freaking out.
Perhaps Alex can post which version(RC1,RC2, etc) this was fixed on????
I'll look through the CVS logs, perhaps I'll get lucky.