[JBoss-dev] [ jboss-Bugs-812620 ] On RC5 - jbossCMP optimistic locking - updating nulled value

[SourceForge.net <no...@so...>]

Bugs item #812620, was opened at 2003-09-25 11:52
Message generated for change (Comment added) made by ioparra
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=812620&group_id=22866

Category: JBossCMP
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Parra (ioparra)
Assigned to: Nobody/Anonymous (nobody)
Summary: On RC5 - jbossCMP optimistic locking - updating nulled value

Initial Comment:
Alex-



Great job on cleaning up CMP optimistic locking.  I've 

been following the changes from 3.2.1 to the latest 

HEAD release.



It seems that you've fixed a large part of the problems 

related to optimistic locking and when, on commit, the 

SQL is created to update rows that may have been null.  

It seems that the order of the where clause is not 

matching the order of the set<Type>.  Here's an 

example from Branch3_2(RC5 from 9/25).



My environment is Oracle9i, JDK1.4, Win2k Prof, 

running RC5(ie Branch_3_2). modified-strategy



DB Schema:

CREATE TABLE Team

(

       TEAM_ID                   NUMBER(15),

       TEAM_OWNER_PERSON_ID      NUMBER(15) NULL,

       TEAM_NAME                 VARCHAR2(100) NULL,

       TEAM_CREATION_DATE        DATE NULL,

       TEAM_CREATED_BY           NUMBER(15) NULL,

       TEAM_LAST_UPDATE_DATE     DATE NULL,

       TEAM_LAST_UPDATED_BY      NUMBER(15) NULL

);





I first do a create(long) to create the row, then set the 

individual values.  Only at commit are these values 

trully updated.  Here's the output with trace turned on:



[Team] Executing SQL: INSERT INTO TEAM(TEAM_ID, 

TEAM_NAME, TEAM_CREATION_DATE, 

TEAM_CREATED_BY, TEAM_LAST_UPDATE_DATE, 

TEAM_LAST_UPDATED_BY, TEAM_OWNER_PERSON_ID) 

VALUES (?, ?, ?, ?, ?, ?, ?)

[id] Set parameter: index=1, jdbcType=BIGINT, 

value=3

[name] Set parameter: index=2, jdbcType=VARCHAR, 

value=NULL

[creationDate] Set parameter: index=3, 

jdbcType=TIMESTAMP, value=NULL

[createdBy] Set parameter: index=4, 

jdbcType=BIGINT, value=NULL

[lastUpdateDate] Set parameter: index=5, 

jdbcType=TIMESTAMP, value=NULL

[lastUpdatedBy] Set parameter: index=6, 

jdbcType=BIGINT, value=NULL

[id] Set parameter: index=7, jdbcType=BIGINT, 

value=NULL



This part is fine.  During commit, I get this trace.



11:13:32,745 DEBUG [PoolThread-8][Team] Executing 

SQL: UPDATE TEAM SET TEAM_NAME=?, 

TEAM_CREATION_DATE=?, TEAM_CREATED_BY=?, 

TEAM_LAST_UPDATE_DATE=?, 

TEAM_LAST_UPDATED_BY=?, 

TEAM_OWNER_PERSON_ID=? WHERE TEAM_ID=? AND 

TEAM_NAME=? AND TEAM_CREATION_DATE=? AND 

TEAM_CREATED_BY=? AND 

TEAM_LAST_UPDATE_DATE=? AND 

TEAM_LAST_UPDATED_BY=? AND 

TEAM_OWNER_PERSON_ID=?

[name] Set parameter: index=1, jdbcType=VARCHAR, 

value=foobar

[creationDate] Set parameter: index=2, 

jdbcType=TIMESTAMP, value=Thu Sep 25 11:13:32 

PDT 2003

[createdBy] Set parameter: index=3, 

jdbcType=BIGINT, value=100

[lastUpdateDate] Set parameter: index=4, 

jdbcType=TIMESTAMP, value=Thu Sep 25 11:13:32 

PDT 2003

[lastUpdatedBy] Set parameter: index=5, 

jdbcType=BIGINT, value=100

[id] Set parameter: index=6, jdbcType=BIGINT, 

value=201

[id] Set parameter: index=7, jdbcType=BIGINT, 

value=3

[lastUpdateDate] Set parameter: index=8, 

jdbcType=TIMESTAMP, value=NULL

[id] Set parameter: index=9, jdbcType=BIGINT, 

value=NULL

[lastUpdatedBy] Set parameter: index=10, 

jdbcType=BIGINT, value=NULL

[createdBy] Set parameter: index=11, 

jdbcType=BIGINT, value=NULL

[name] Set parameter: index=12, jdbcType=VARCHAR, 

value=NULL

[creationDate] Set parameter: index=13, 

jdbcType=TIMESTAMP, value=NULL

[LogInterceptor] TransactionRolledbackException in 

method: ...

org.jboss.tm.JBossRollbackException: Unable to 

commit, tx=TransactionImpl:XidImpl [FormatId=257, 

GlobalId=MyMachine//51, BranchQual=] 

status=STATUS_NO_TRANSACTION; - nested 

throwable: (javax.ejb.EJBException: Store failed; 

CausedByException is:

        ORA-00932: inconsistent datatypes: expected 

NUMBER got TIMESTAMP

)

        at org.jboss.tm.TransactionImpl.commit

(TransactionImpl.java:408)

...



Caused by: javax.ejb.EJBException: Store failed; 

CausedByException is:

        ORA-00932: inconsistent datatypes: expected 

NUMBER got TIMESTAMP

        at 

org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityComman

d.execute(JDBCStoreEntityCommand.java:177)

        at 

org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.store

Entity(JDBCStoreManager.java:649)

        at 

org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity

(CMPPersistenceManager.java:421)

     

You can see that the insert types are in sync during the 

create stage but are out-of sync during the optimistic 

WHERE clause.  



If I have time, I'll look through the code and see if I 

can patch it.  I know that RC5 has not been released 

and, because of that, this bug may not be a priority.  

Figured there would be no harm on posting a bug 

now. :)



-Ivan



----------------------------------------------------------------------

>Comment By: Ivan Parra (ioparra)
Date: 2003-09-25 13:41

Message:
Logged In: YES 
user_id=812998

Looks like the source is during the WHERE clause, a call 

to "optimisticeLock.getGetLockedFields()"  returns an array of 

JDBCCMPFieldBridge[].  I think the assumption is that this 

array is based on some concrete order.



If you look in the 

JDBCOptimistLock.LockingStrategy.getLockedFields(), you 

see that this is actually a Map.  The order of these fields are 

then compared against the tableFields.  Because of the Map, 

these mappings will never work.

The where clause is built on a whereMask compared against 

the tableFields that where generated by the lockedFields.  

Then the update statement is generated by lockedFields.  



I've tried changing the code based on the tableFields instead.



There are some inherent problems in the SQL design. The 

where clause is based of a MASK.  The first argument set is 

the primary key, then the locked fields.  This works GREAT iff 

the primary key fields are the first values in the table.  If, for 

example, the primary key is the first/last column of the 

table, this won't work.





Needless to say, after I patched the code to make it work, 

the NULL matching failed again.  :(









----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=812620&group_id=22866