geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohammed Nour" <nour.moham...@gmail.com>
Subject Re: Pessimistic locking strategy for CMP beans in 1.1.1
Date Thu, 27 Jul 2006 12:19:28 GMT
Hi Matt...

On 7/27/06, Matt Hogstrom <matt@hogstrom.org> 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.
>

Mime
View raw message