This is great!! Can you please explain how this implementation uses transactions and what transaction isolation settings it requires or assumes? Does this implementation result in each JBoss jta transaction getting its own copy of any entity it accesses?
Is it possible to setup optimistic locking without useing any extra checks or fields on a database such as firebird that natively supports aptimistic locking through versioning? (On Firebird with Jaybird driver, setting isolation to Repeatable Read results in each transaction getting a snapshot of the database. If one transaction tries to modify a record already modified by another transaction, you get an exception. It is also possible to configure so the 2nd transaction waits for the first to complete before deciding whether to throw an exception.) Thanks! david jencks On 2002.12.26 03:50:57 -0500 Alex Loubyansky wrote: > To setup optimistic locking, container configuration element > 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 > > ------------------------------------------------------- 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
