Bugs item #1006723, was opened at 2004-08-10 19:56
Message generated for change (Comment added) made by loubyansky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1006723&group_id=22866
Category: JBossCMP
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ivan Parra (ioparra)
Assigned to: Alexey Loubyansky (loubyansky)
Summary: Optimistic CMP/CMR with version-column + on-load
Initial Comment:
Win2K
JDK1.3.1_06
JBoss3.2.5
Container configurations
(on-load, cached, invalidation, optimistic)
Steps to reproduce the bug:
I haven't tested this exact setup, to my knowledge, this
give the same results.
Table A{ pk, oca }
Table B{ pk, a_pk, oca}
For both tables, OCA is used for optimistic locking
(verrsion-column) and is initialized to a number(either by
initial insert or create via ejb).
Relation from A->B is one to many. The initial
environment is like so.
A1->B1
A2->B2
When we run this pseudo code:
B1 = findByPrimaryKey(b1_pk)
A2 = findByPrimaryKey(a2_pk)
ArrayList list = new ArrayList();
list.add(b1);
A2.setBs(list);
The new state should be:
A2->B1
A1 (no relation)
B1 (no relation)
When we run this code with on-find, it runs fine. With
on-load, it fails with this exception snippet:
INFO [STDOUT] + nested throwable:
INFO [STDOUT] javax.ejb.EJBException: Update failed.
Expected one affected row: rowsAffected=0, id=42
INFO [STDOUT] at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.
execute(JDBCStoreEntityCommand.java:155)
INFO [STDOUT] at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEn
tity(JDBCStoreManager.java:635)
INFO [STDOUT] at
org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity
(CMPPersistenceManager.java:395)
INFO [STDOUT] at
org.jboss.resource.connectionmanager.CachedConnection
Interceptor.storeEntity
(CachedConnectionInterceptor.java:387)
I turned on DEBUG/TRACE to see what the query was
and found these 2 queries. Notice how the first query is
created incorrectly and mid-setup, the second query is
ran. Also notice that the failure occurred not on the
assignment of the new relation, but the disassociations
of the old(ie... B2 removing itself from A2)
1) DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand
.AppConfig] Executing SQL: UPDATE B SET A_PK=?,
OCA=? WHERE PK=? AND OCA IS NULL
TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBrid
ge.B#pk] Set parameter: index=1, jdbcType=BIGINT,
value=NULL
2) DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.
AppConfig] Executing SQL: SELECT OCA FROM B WHERE
(PK=?)
TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBrid
ge.B#pk] Set parameter: index=1, jdbcType=BIGINT,
value=42
TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCLongVersionFi
eldBridge.B#version_lock] Set parameter: index=2,
jdbcType=INTEGER, value=4
TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBrid
ge.B#id] Set parameter: index=3, jdbcType=BIGINT,
value=42
Because of the ordering, the first SQL has ORA is NULL.
Then the ora is selected(but is to late).
---
When I run this exact same code with on-find, it runs
just fine. I can only suspect it works because B2's OCA
is pre-loaded.
Let me know if you need more information or exact test-
case.
-Ivan
----------------------------------------------------------------------
>Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-08-11 23:36
Message:
Logged In: YES
user_id=543482
That's all.
----------------------------------------------------------------------
Comment By: Ivan Parra (ioparra)
Date: 2004-08-11 23:33
Message:
Logged In: YES
user_id=812998
Okay. I'll put a test case together from the current
Branch_3_2 branch.
So that I don't duplicate our efforts, what did you reproduce
and fix? From the code, it looks like your checking if the OCA
was initialize to NULL. Is that all that was fixed or is there
more?
-Ivan
----------------------------------------------------------------------
Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-08-11 20:27
Message:
Logged In: YES
user_id=543482
I fixed what I could reproduce. If you still have a problem
after the fix then reopen and if possible provide a
testcase. Thanks.
----------------------------------------------------------------------
Comment By: Ivan Parra (ioparra)
Date: 2004-08-11 19:43
Message:
Logged In: YES
user_id=812998
I had a look at your fix:
JDBCLongVersionFieldBridge(is the only file).
It looks like you added logic to check for a possible null value
then assign the FIRST_VERSION.
It my test case, I made sure the each OCA was set to some
value. I was assuming that this may be a migration issue and
confirm initializing the OCA to 1 AND tried by allowing the
appserver to set the value on create.
If you notice, the TRACE with B#version_lock is being set to 4
for the 2nd value(updateing the OCA value). That would
imply that the OCA was 3. That would also explain why the
2nd query occurs mid-update(to find the OCA value is in fact
3).
-Ivan
So am I to reopen this or will you automatically get emailed.
Don't want to seem pestering. :)
----------------------------------------------------------------------
Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-08-11 13:45
Message:
Logged In: YES
user_id=543482
Fixed in 3.2.6rc2. Thanks.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1006723&group_id=22866
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
