4

I'm wondering how to handle optimistic lock version property in entity class using JPA (toplink essentials) from server to client and vice versa.

Here is the scenario.

  1. From browser user send request to the server asking for individual user info to edit.

  2. Server processes the request and return the result to the browser. The server code looks something like:

    EntityManager em = EmProvider.getInstance().getEntityManagerFactory().createEntityManager();

    User u = (User)em.find(User.class, myUserId);

    return u; //response back to the browser

Here, my confusion is User table has "version" column for optimistic locking.

That means value of version field is also sent back to the client even though the client (me or anyone) would never use it. The version field is to be used in server side code.

So is it correct to send version number to client? Because otherwise I can't figure out how to check version number in case user clicks on "UPDATE" button on web page with modified data.

Please let me know if you need more clarification.

Meow
  • 18,371
  • 52
  • 136
  • 180
  • If that data identifies a user, then how it could be modified by someone else without him noticing? And if he modified the data in another browser instance, and then saves this instance then shouldn't it overwrite what was saved before? – Luciano Jan 05 '11 at 02:19
  • @Luciano: If I understand your point correctly.. the version sent to client is not going to be editable or I can put in hidden field etc the version value won't identifies the user himself, it helps to see if the same record has been updated by other users such as ... well admin?? – Meow Jan 05 '11 at 02:25
  • If the version remains hidden in something like a javascript variable, then the user can change it before sending the message back to the server. I think it would be better to store the User object in the server session and then modify that object with what comes back from the browser, without changing the version number, and then persist/merge that object. – Luciano Jan 05 '11 at 03:05
  • @Luciano: That's good point. Actually I forgot to mention i'm using REST so it has to be stateless (i.e. can't use session I assume). – Meow Jan 05 '11 at 07:32

1 Answers1

5

Yes, you would send the version number to the client, so that he can later send it back to the server (together with the changes he wants to do to the entity), who can use it to check for conflicting updates.

How else would the server know against which version to check? (One could also put the number in a server-side session, but that is basically a variation on the same theme). The point is that when you "check out" the version to edit, you carry the version number from that point in time along.

That means value of version field is also sent back to the client even though the client (me or anyone) would never use it.

Well, you could use it on the client. For example if the editing operation takes a long time, the client could poll once in a while if the entity has concurrently been updated, and then alert the user about it. (Similar to the "A new answer has been posted" message here on Stackoverflow).

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • Thanks for the tip! I was hesitating to include that extra piece of data (i.e. version) but appeared to be really important piece :) – Meow Jan 05 '11 at 02:23
  • We can change the version number from front end (javascript). Then how will optimistic lock work in this case ? – Rumel Apr 13 '21 at 05:58
  • This is a cooperative scheme, it does not work if the client does not pass along the correct version number. If you send the wrong version number the update will either be rejected or you will be able to blindly override a version you have not seen. – Thilo Apr 13 '21 at 07:06
  • @Thilo You describe an approach I would very much agree. Actually in JPA spec it is forbidden to change an attribute annotated with `@Version`. So in case my client has a serialized version of an entity, how can I tell JPA on server side which version number I got from a client? I once asked a separate question about this [Does JPA @Version feature play well with DTOs?](https://stackoverflow.com/q/73191718/5176800). Maybe you have an opinion on this topic :-) – Filou Apr 18 '23 at 05:51