I don't mean to sound like a dumbass, but is there anywhere that explains what scenarios optimistic locking is best for (i.e. a place I can figure out if I should use it)?
Thanks, Hunter > From: Alex Loubyansky <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Thu, 26 Dec 2002 18:12:36 +0200 > To: David Jencks <[EMAIL PROTECTED]> > Subject: Re[2]: [JBoss-user] Optimistic locking ported to JBoss-3.2 > > DJ> Can you please explain how this implementation uses transactions and what > DJ> transaction isolation settings it requires or assumes? > > When transaction/new transaction comes, JDBCOptimisticLock locks > fields and their values depending on the strategy used. Fields and > field values are locked per each tx. > > For version columns and field group strategies, fields that are used > in locking and their values are locked when tx reaches entity. > > For read and modified strategies, when tx reaches entity, all > entitie's field values are locked but not the fields itself. Later, > when a field is read/modified the field is actually locked. > > DJ> Does this > DJ> implementation result in each JBoss jta transaction getting its own copy > of > DJ> any entity it accesses? > > Here you caught me... it occurs it's not so great. > Using "Standard CMP 2.x EntityBean" container entities are shared > between transactions. So, if some tx changes some field, another tx > will see it. > Using "Instance Per Transaction 2.x EntityBean" doesn't solve it > either. > > DJ> Is it possible to setup optimistic locking without useing any extra checks > DJ> or fields on a database such as firebird that natively supports aptimistic > DJ> locking through versioning? > > No, no vendor support for now. > > Thanks, > alex > > DJ> (On Firebird with Jaybird driver, setting isolation to Repeatable Read > DJ> results in each transaction getting a snapshot of the database. If one > DJ> transaction tries to modify a record already modified by another > DJ> transaction, you get an exception. It is also possible to configure so > the > DJ> 2nd transaction waits for the first to complete before deciding whether to > DJ> throw an exception.) > > DJ> Thanks! > > DJ> david jencks > > > DJ> 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-polic >>> y> >>> 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 > > > -- > Best regards, > Alex Loubyansky > > > > > ------------------------------------------------------- > 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
