Alex Loubyansky wrote:
To setup optimistic locking, container configuration elementHi.
locking-policy should be set to
<locking-policy>org.jboss.ejb.plugins.lock.JDBCOptimisticLock</locking-policy>
and entity element in jbosscmp-jdbc.xml should have optimistic-locking
element.
Following are the possible configurations of optimistic-locking element:
1. Fixed group of fields that will be used for optimistic locking.
<optimistic-locking>
<group-name>optimisticLockingGroup</group-name>
</optimistic-locking>
where optimisticLockingGroup is one of the entity's load-group-name's.
2. Modified strategy. The fields that were modified during transaction
will be used for optimistic locking.
<optimistic-locking>
<modified-strategy/>
</optimistic-locking>
3. Read strategy. The fields that were read during transaction will be
used for optimistic locking.
<optimistic-locking>
<read-strategy/>
</optimistic-locking>
4. Version (counter) column strategy. Additional version (counter)
field of type java.lang.Long will be added to entity which
will be used for optimistic locking. Each update of the entity will
increase the value of its version field by 1.
<optimistic-locking>
<version-column/>
<field-name>versionField</field-name>
<column-name>ol_version</column-name>
<jdbc-type>INTEGER</jdbc-type>
<sql-type>INTEGER(5)</sql-type>
</optimistic-locking>
5. Timestamp column strategy. Additional timestamp column field of
type java.util.Date will be added to entity which will be
used for optimistic locking. Each update of the entity will set the
value of its timestamp field to the current time.
<optimistic-locking>
<timestamp-column/>
<field-name>timestampField</field-name>
<column-name>ol_timestamp</column-name>
<jdbc-type>TIMESTAMP</jdbc-type>
<sql-type>DATETIME</sql-type>
</optimistic-locking>
6. Version column generated by KeyGenerator. Additional field will be
added to entity that will be used for optimistic locking. Each update
of the entity will update its version column with value generated by KeyGenerator.
<optimistic-locking>
<key-generator-factory>UUIDKeyGeneratorFactory</key-generator-factory>
<field-type>java.lang.String</field-type>
<field-name>uuidField</field-name>
<column-name>ol_uuid</column-name>
<jdbc-type>VARCHAR</jdbc-type>
<sql-type>VARCHAR(32)</sql-type>
</optimistic-locking>
alex
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Does it make any sense using commit-option A with "Instance Per Transaction" container (a.k.a optimistic lock policy)?
I mean - when the second tx reaches an already enlisted entity bean (in the first tx) I guess the bean data is read from the DB anyway (and not from the cache). Is this correct?
Thanks.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
