Hi, I currently have some problems with entity version checks / optimistic locking using JPA on server side and I wonder how RequestFactory would handle my problem.
Currently the application I am working on has an auto save mechanism. That means each time the user changed some data the application will wait a couple of milliseconds and if no additional changes are made during this time the application sends a save command (command / dispatch pattern) to the server. The server then loads the JPA entity from the database and compares its entity version with the one provided by the client entity that was send with the save command. If they match, data will be copied from client entity to the JPA entity and then saved to our database. When the entity is saved we return the new entity version to the client application which updates it in the client entity object. If they do not match, an exception will be thrown and the client application reloads the object and updates the UI because the database contains newer data. Our server is pretty stateless and we have one transaction per request. So its similar to RequestFactory. We have a client entity class and a JPA entity and copy data between them on server side (along with some computations if needed). Now our problem: As we do our auto save quite instant (about 100-300 ms after the last user input) it may happen that we fire two or more save commands without getting a response from our server because the network connection is bad (basically the round trip time would be longer as our auto save timer / 100-300ms). Thus the second save command will fail because the first one results in an updated entity version in our database but the client does not now about it yet and thus the second save command contains the same entity version as the first one. How would RequestFactory handle such a situation? What happens if you call xxxRequest.persist().using(object).fire() twice without having received a result during both calls (what could happen if we integrate RF instead of a command pattern)? I know that RequestFactory currently does no real optimistic lock check (http://code.google.com/p/google-web-toolkit/issues/detail?id=6046) because it somehow disappeared in the source code. But how would it handle entity versions to make sure optimistic locking works? Are entity versions stored in the generated proxy classes or is there a server side map that remembers all entity proxys with their entity versions that have been delivered to the client? How do you do optimistic checking in your application and how do you have solved this issue? Do you just make sure the client application can only fire a second save request when the first one is done successfully? Currently we have increased our auto save timer by temporarily adding a factor of 10. So we auto save about 3 seconds after the last user input (although this causes some other problems like doing a forced auto save when the user navigates to a different application place within this 3 seconds) to somehow compensate a poor network quality. We would really like to use RequestFactory in the future to get rid of the command pattern and all that server side copy code but in the meantime we can maybe adopt some RequestFactory ideas and integrate them in our command pattern to solve our issue. I really appreciate any helpful thoughts! -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
