Yeah, i see. You implement manual version control in your project. But, I decided to use RF in my project to forget about transmission domain objects between server and client.
In general, it is unclear why the guys at Google have made the RF this way. On Wednesday, June 10, 2015 at 2:51:48 AM UTC+3, Jens wrote: > > We don't use RequestFactory but GWT-RPC with Eclipselink + optimistic > locking and heavy auto saving. Because we don't want to live with the extra > query when doing the em.find / detach / update version / merge dance we > simply do the version check manually in the app. Also we don't send > versions to the client, we keep track of them on the server only. > > On server side we have a class called EntityVersionStore and each user > session has exactly one instance of it. This store is transactional just > like the EntityManager so you can do EVS.beginTransaction() / rollback() / > flush() / commit(). Then we have a EVS.remember(Entity) method that can > only be called within an active transaction and simply stores the current > entity version inside an internal map. > To do the optimistic lock checking we have EVS.checkVersion(Entity) which > compares the current entity version against the version that has been > flushed() or committed() to the store previously. Finally we have @PostLoad > and @PostUpdate hooks in a base entity that simply call EVS.remember(this) > whenever an entity is loaded from DB or saved to DB. > > So when a request reaches the server the overall workflow is > > 1. entityManager.beginTransaction() > 2. evs.beginTransaction() > 3. dispatch command to a handler (we use command pattern) > 4. Inside the handler we load entities which causes the @PostLoad hook of > those entities to be executed (evs.remember(this)) > 5. Manually compare versions via evs.checkVersion(entityToEdit). As > checkVersion() only works on flushed/committed data the version remembered > in 4. is not used. Instead the version of any previous request is used as > that data is committed. > 6. If version checks passes continue modifying the entities and save them > to DB > 7. entityManager. commit() > 8. @PostUpdate hook executes for all updated entities and EVS will be > updated just like in 4. > 9. evs.commit() to make all the remembered versions of that current > request committed so that the next request can use that information when > calling checkVersion. > > > Works pretty transparent for us, as the only thing we need to do is to > call evs.checkVersion() before updating an entity. And with some abstract > handlers for common tasks like saving one entity we don't even have to call > evs.checkVersion() as the abstract handler does this for us. > > > -- J. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
