Thanks Mohammed...that's what I ws looking for. cheers.
Mohammed Nour wrote:
Hi Matt...
On 7/27/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
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.
To make an instance of this XML-Schema contains only one locking strategy,
you have to make it as follows:
<xs:element name="locking-strategy">
<xs:complexType>
<xs:sequence>
<xs:choice>
<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: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:choice>
</xs:sequence>
<xs:complexType>
</xs:element>
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.
