-
1. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
aloubyansky Nov 29, 2004 9:08 AM (in response to jvembuna)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
jvembuna Dec 9, 2004 6:55 AM (in response to jvembuna)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
aloubyansky Dec 10, 2004 12:16 PM (in response to jvembuna)What container configuration are you using?
-
4. Re: Optimistic Locking with Timestamp in 3.2.5 having issues
jvembuna Dec 15, 2004 5:38 AM (in response to jvembuna)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
aloubyansky Dec 16, 2004 3:20 AM (in response to jvembuna)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
jvembuna Dec 20, 2004 6:23 AM (in response to jvembuna)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
jvembuna Dec 20, 2004 6:35 AM (in response to jvembuna)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
aloubyansky Dec 21, 2004 3:52 AM (in response to jvembuna)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
jvembuna Dec 21, 2004 4:01 AM (in response to jvembuna)Hi,
Thanks for your speedy response. I will verify the same with 3.2.6
Regards,
V.Janardhanan