Optimistic Locking Problem in 3.2.2

[ahahamyan]

Please help, I am trying to use the version-column strategy for optimistic locking. I have a table on mysql which has a version column (bigint). I have cmp getter and setters for this column on my entity bean just like other fields. In order to check to see if the client has stale data when updating I am checking version number of the DTO (value object) against the bean's version number in a modify method on the bean class. I also have the following specified in the jbosscmp-jdbc.xml for the entity bean.

<optimistic-locking>
<version-column/>
<field-name>version</field-name>
<column-name>version</column-name>
</optimistic-locking>

When I am creating a new entity bean through ejbcreate, I get the following error which leads me to believe that I cannot have cmp getters/setters on the version field, but I need to be able to check for stale data the client might have had during the "think-time"

jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.User] Executing SQL: INSERT INTO usr(username, password, ftp_username, ftp_password, admin_rights, alter_media, alter_segments, alter_schedules, alter_players, version, version) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#userName] Set parameter: index=1, jdbcType=VARCHAR, value=arnold
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#password] Set parameter: index=2, jdbcType=VARCHAR, value=secret
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#ftpUserName] Set parameter: index=3, jdbcType=VARCHAR, value=firesign-ftp-usr
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#ftpPassword] Set parameter: index=4, jdbcType=VARCHAR, value=firesign-ftp-pass
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#adminRights] Set parameter: index=5, jdbcType=VARCHAR, value=yes
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#alterMedia] Set parameter: index=6, jdbcType=VARCHAR, value=yes
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#alterSegments] Set parameter: index=7, jdbcType=VARCHAR, value=no
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#alterSchedules] Set parameter: index=8, jdbcType=VARCHAR, value=no
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#alterPlayers] Set parameter: index=9, jdbcType=VARCHAR, value=yes
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.User#version] Set parameter: index=10, jdbcType=BIGINT, value=NULL
2003-11-13 21:59:41,224 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCLongVersionFieldBridge.User#version] Set parameter: index=11, jdbcType=BIGINT, value=1
2003-11-13 21:59:41,264 ERROR [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.User] Could not create entity
java.sql.SQLException: General error, message from server: "Column 'version' specified twice"

[jcordes]

I had exactly the same problem when using JBoss 3.2.2. Even a look at the source of org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge and modifications didn't made a difference. With audit-fields it'works seamlessly. Maybe there's a reason behind it, why the version column is not exposed (and only used internally). Checking for stale data would be easy, if it's exposed. Would this be an enhancement ?

TIA,

Jochen.

[ahahamyan]

This looks like a bug, I created a bug report for it at http://sourceforge.net/tracker/index.php?func=detail&aid=842237&group_id=22866&atid=376685

[senthilcool]

Do you have a <cmp-field> defined for the version column in your ejb-jar.xml and jbosscmp-jdbc.xml files?
If so, try removing the <cmp-filed> definitions. The <optimistic-locking> definition should be enough for the getters/setters to work. I have tried this with the timestamp-column strategy (must be the same with the version-column)

[ahahamyan]

that is what it was. It is working great now. Thanks