lost update issue

on my server is a weblogic cluster ejb2 application. There is this table in the DB where other users will concurrently create, update and delete.

On my clients machines is a rich client java application. How do i send delta updates of the changes and yet still maintain a consistent always correct view of the table? (hence no lost update, if a lost update could be detected, a recovery mechanism will be required to resync the view)

I thought of 开发者_JAVA技巧the idea of Subversion global revision number, but I don't know how to implement it as the application is on a cluster.

any idea on how to go about it?

What kind of EJBs does your application contain?

Stateless session bean

How does the other users access to this table?

apache httpclient to JSP via stateless session bean with jdbc connection

Where does that update get lost?

each client will execute a pull of the entire table on startup. Subsequent updates of the delta information will be push to the rich client. The lost update happens when a client A is attempting to pull the information, and client B edit the table. As client B edit consisted of delta information, which will be pushed to client A, it might arrive faster. Client A havent received the complete table and hence discard the delta information.

I'm still not sure but you might want to use optimistic locking to implement concurrency control (see the whole article for others strategies). Optimistic locking is pretty easy to implement. One option is to:

Mark the source with a unique identifier. The source data row is marked with a unique value each time it is updated. At the point of update, the mark is checked, and if there is a different value than what you originally read in, then you know that there has been an update to the source.

Using a incremental counter is one of the possible concurrency mark. The idea is to add a version number to you entities and to increment it each time on save.

Image you read a record which has VERSION_NUM = n. If the following update request fails:

UPDATE T 
SET VERSION_NUM = VERSION_NUM + 1 [,column_name = value ...] 
WHERE VERSION_NUM = n [AND ...]

Then someone has already updated the record while you were editing it.