I wanted to let people know about one of the fixes I'm putting into 1.1.1. I addressed this issue
in a note previously and it has to do with our locking model for CMP persistence. This note is
applicable to OpenEJB-2.1.1-SNAPSHOT as well as TranQL 1.3.1-SNAPSHOT.
Currently users deploying CMP beans have no mechanism to specify if they want to lock the row in a
DB when they execute a finder on a CMP entity. This means that there is no locking in the database
and multiple concurrent users have a high degree of either corrupting data or getting SQL -911
deadlocks in their application.
To mitigate this issue I am adding a few new elements to the OpenEJB schema to allow users to
specify this option. Here is my current thinking and I'd like some feedback if you have time and
are interested.
Basically there are two ways locking is implemented. The first is a pessimistic strategy that
relies on the database to enforce locking. Unfortunately, different DBMS's have various ways to
address this. It is generally accomplished by setting the appropriate isolation level and
specifying *for update* on the select clause. I believe that with the knowledge of a pessimistic
strategy the DBSyntaxGenerators in TranQL can put out the appropriate SQL to accomplish this.
The second method is to use an optimistic strategy where a mono incrementing column or timestamp is
used to disambiguate tuples from each other. The container keeps track of the value of the
optimistic column. I'm planning on implementing this later but thought we'd make the schema changes
now.
I would like to add a <locking-strategy> section to the entity-bean element
after the pre-fetch group.
The locking strategy really is either optimistic or pessimistic. Currently I'm focusing on
pessimistic and need to finalize the optimistic options but this is enough for discussion.
Something like:
<xs:element name="locking-strategy">
<xs:complexType>
<xs:sequence>
<xs:element name="optimistic-locking" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="optimistic-column"
type="xs:string"/>
<xs:element name="optimistic-type"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType>
<xs:sequence>
<xs:element name="pessimistic-locking" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="select-for-update"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
This seems clunky to me...is there a better way to express this idea as the locking strategy
requires one or the other but not both. I think the above is ok and will validate in the builder
but want some feedback.
Here is what I would expect a user to code:
<entity>
<ejb-name>KeyGenEJB</ejb-name>
<table-name>KeyGenEJB</table-name>
<cmp-field-mapping>
<cmp-field-name>keyVal</cmp-field-name>
<table-column>keyVal</table-column>
</cmp-field-mapping>
<cmp-field-mapping>
<cmp-field-name>keyName</cmp-field-name>
<table-column>keyName</table-column>
</cmp-field-mapping>
<locking-strategy>
<pessimistic-locking>
</locking-strategy>
.
.
or
.
.
<locking-strategy>
<optimistic-locking>
<optimistic-column>occColumn</optimistic-column>
<optimistic-type>TIMESTAMP</optimistic-type>
</locking-strategy>
</entity>
BAH...NOTE I wrote this abot 8 hours ago and here it sits unsent...bummer.
Well, here it is now.
