9 Replies Latest reply on Dec 21, 2004 4:01 AM by Janardhanan Vembunarayanan

    Optimistic Locking with Timestamp in 3.2.5 having issues.

    Janardhanan Vembunarayanan Newbie

      Hi,

      We are using Jboss version 3.2.5 and tried to implement optimistic locking with timestamp approach. The scenario which we are having is

      1. Client A gets the data from the session facade which uses a CMP and gets the value object to display the data.

      2. Client A changes the data through the web interface.

      3. Client B does an update to the same data and the timestamp column gets modified in the DB.

      4. Client A tries to update the data with the previous timestamp it has got by passing in the valueobject.

      5. While saving the data the Container is using the value set by client B in the where clause. Hence no error is thrown and the lost update is happening.

      Is there a way by which I can set the value of the timestamp to be compared in the where clause?

      Any pointers in this regard will be really helpful.

      Regards,
      V.Janardhanan

        • 1. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
          Alexey Loubyansky Master

          Hi,

          We are having an update web page where the data from Customers table is displayed to the user. We are using valueobjects to transfer the data to the web tier. There are 2 clients

          Client 1 Client 2
          --------- ---------
          views the data ***
          *** views the same data
          *** updates the data
          updates the data ***

          Both are allowed the updates. when both the users viewed the data the sql was

          select address2
          ,modifieddate
          ,...
          from customers
          where customerid = 41

          The output was

          address2 Timestamp
          ---------- ------------
          B 02-dec-2004 17:33:35

          When client2 updated the record the query was

          UPDATE CUSTOMERS SET address2='C', modifieddate='Thu Dec 09 17:10:58 IST 2004' WHERE customerid=41 AND modifieddate='Thu Dec 02 17:33:35 IST 2004'

          In the where clause it uses the timestamp fetched above(While updating we are doing a finder and then calling the setter)

          When client1 updated the record the query was

          UPDATE CUSTOMERS SET address2='D', modifieddate='Thu Dec 09 17:11:41 IST 2004' WHERE customerid=41 AND modifieddate='Thu Dec 09 17:10:58 IST 2004'

          In the where clause it uses the timestamp of the client 2 updates as we are invoking a finder again. This is the reason for lost updates.

          Is there are way by which we can give the timestamp which we the client has rather than getting the latest and comparing it which always will be correct?

          Regards,
          V.Janardhanan

          • 2. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
            Janardhanan Vembunarayanan Newbie

            Hi,

            We are having an update web page where the data from Customers table is displayed to the user. We are using valueobjects to transfer the data to the web tier. There are 2 clients

            Client 1 Client 2
            --------- ---------
            views the data ***
            *** views the same data
            *** updates the data
            updates the data ***

            Both are allowed the updates. when both the users viewed the data the sql was

            select address2
            ,modifieddate
            ,...
            from customers
            where customerid = 41

            The output was

            address2 Timestamp
            ---------- ------------
            B 02-dec-2004 17:33:35

            When client2 updated the record the query was

            UPDATE CUSTOMERS SET address2='C', modifieddate='Thu Dec 09 17:10:58 IST 2004' WHERE customerid=41 AND modifieddate='Thu Dec 02 17:33:35 IST 2004'

            In the where clause it uses the timestamp fetched above(While updating we are doing a finder and then calling the setter)

            When client1 updated the record the query was

            UPDATE CUSTOMERS SET address2='D', modifieddate='Thu Dec 09 17:11:41 IST 2004' WHERE customerid=41 AND modifieddate='Thu Dec 09 17:10:58 IST 2004'

            In the where clause it uses the timestamp of the client 2 updates as we are invoking a finder again. This is the reason for lost updates.

            Is there are way by which we can give the timestamp which we the client has rather than getting the latest and comparing it which always will be correct?

            Regards,
            V.Janardhanan

            • 3. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
              Alexey Loubyansky Master

              What container configuration are you using?

              • 4. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
                Janardhanan Vembunarayanan Newbie

                Hi,

                We are using the 'Optimistic Container'. In the JBoss.xml we have the following entry

                <container-configurations>
                <container-configuration
                extends="Instance Per Transaction CMP 2.x EntityBean">
                <container-name>Optimistic Container</container-name>
                <locking-policy>
                org.jboss.ejb.plugins.lock.JDBCOptimisticLock
                </locking-policy>
                </container-configuration>
                </container-configurations>

                and all the entity beans is having the following line.


                <ejb-name>Businesstype</ejb-name>
                <local-jndi-name>BusinesstypeLocal</local-jndi-name>
                <configuration-name>Optimistic Container</configuration-name>
                <method-attributes>
                </method-attributes>


                Regards,
                V.Janardhanan

                • 5. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
                  Alexey Loubyansky Master

                  That looks ok. Maybe the problem is 'JBoss.xml'. Try 'jboss.xml' instead.
                  Also, fyi, JDBCOptimisticLock is deprecated since after 3.2.2 it does nothing. You can use just IPT container as is instead.

                  • 6. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
                    Janardhanan Vembunarayanan Newbie

                    Hi,

                    Thanks for your quick response.

                    The scenario is same as given in the issue

                    http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57794.

                    The reading and writing of data are happening in two different transactions. Hence the container takes what is there currently in the database(timestamp) and add the same in the where clause and the update suceeds without any issue.

                    Our requirement is that we need the optimistic lock to be applied even when the read and writes are in 2 different transactions. Probably we need to do this check at our application level. Have a method in our EntityBean called checkConflicts which compares the version with the client and the one in the db.

                    Is my understanding correct?

                    If it is correct then in a web based enviroment most of the requirement will be of the same kind. How will the optimistic container be useful?


                    Regards,
                    V.Janardhanan

                    • 7. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
                      Janardhanan Vembunarayanan Newbie

                      Hi,

                      I found a small issue with the optimistic container. Unless we call the getLastUpdateDate() the container is adding the where clause as null.

                      i.e.

                      //Group table has a CMR to users table
                      Collection c = grouplocal.getUsers();
                      Iterator i = c.iterator();
                      while(i.hasNext())
                      {
                      UserLocal user = (UserLocal)i.next();
                      user.setSomething();
                      }

                      Since we are using the optimistic container, in the where clause it is adding the following

                      where userid =? and modifieddate is null

                      With the following code the modifiedddate is set currently

                      //Group table has a CMR to users table
                      Collection c = grouplocal.getUsers();
                      Iterator i = c.iterator();
                      while(i.hasNext())
                      {
                      UserLocal user = (UserLocal)i.next();
                      user.getModifiedDate();
                      user.setSomething();
                      }

                      where userid =? and modifieddate = ?

                      Think it should take the value for date in the where clause irrescpective of we are calling the getter or not.

                      Regards,
                      V.Janardhanan

                      • 8. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
                        Alexey Loubyansky Master

                        The link you posted as a testcase describes expected behaviour.
                        The 'is null' issue might be fixed in 3.2.6. I remember I fixed something like this once.
                        Sorry, I don't have much time to investigate this. Please, try the latest JBoss release (3.2.6), write a simple testcase that shows the problem (you seem to be pretty close to this) and open an issue at jira.jboss.com.
                        We have optimistic locking tests here
                        http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/src/main/org/jboss/test/cmp2/optimisticlock/
                        And DDs in the src/resources. Have a look.
                        Thanks.

                        • 9. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
                          Janardhanan Vembunarayanan Newbie

                          Hi,

                          Thanks for your speedy response. I will verify the same with 3.2.6

                          Regards,
                          V.Janardhanan