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: Open
>Resolution: Accepted
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-09-29 20:29
Message:
Logged In: YES
user_id=543482
Yes, I see it. Thanks.
----------------------------------------------------------------------
Comment By: Cuen Edwards (jcuen)
Date: 2004-09-29 16:43
Message:
Logged In: YES
user_id=532328
I do not seem to be able to upload the testcase - probably
because I am not a member of the project.
I have, however, emailed the testcase to your jboss email
address.
Thanks
----------------------------------------------------------------------
Comment By: Alexey Loubyansky (loubyansky)
Date: 2004-09-28 23:59
Message:
Logged In: YES
user_id=543482
Please, provide a testcase.
----------------------------------------------------------------------
Comment By: Cuen Edwards (jcuen)
Date: 2004-09-28 14:51
Message:
Logged In: YES
user_id=532328
As described by Ivan, this bug still exists, so it should be
reopened.
I have also found that this bug does not occur if the read-
ahead strategy is changed to on-find.
I am not at all familiar with the JBoss source but it seems as
though the following is happening (with on-load):
- When jboss builds up the Where clause of the store entity
prepared statement - the version field has not yet been
loaded. JBoss does not seem to check if the field has been
loaded yet, at this point - and assumes its loaded value is
null.
- Then when jboss sets the prepared statement parameter,
which represents the new value of the version field, it
determines that the field has not yet been loaded and issues
a Select statement (Which is too late as described by Ivan).
Seeing as one has not yet been submitted, I will attempt to
produce a testcase, however I believe that enough
information has been provided, so that anyone with sufficient
insight into the structure of the JBoss source, will be able to
fix this error. (Please also refer to Ivan's trace).
This bug is present in JBoss 3.2.6 RC1 and JBoss 4.0.
----------------------------------------------------------------------
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
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
