GWT RequestFactory Hibernate unnecessary call find method in locator

Using RequestFactory I gets data to View, then in other transaction someone else updating this object to version 1 (My view has still version 0). Next I update some values and push changes by RequestFactory to DAO Layer. The problem is when changed object is transferted to Service Layer: th开发者_运维知识库e Locator calls find method and gets newest version of object (changed by someone else). So when we gets to update method in DAO layer object is merged with version1 and changes from both transaction! In this situation in normal case Hibernate should throw exception because object should has other version value (Optimistic Lock)?

Locator:

@Component
public class TaskItemLocator extends Locator<TaskItem, Long> {     
   @Autowired
   private TaskItemDao taskItemDao;

   @Override
   public TaskItem find(Class<? extends TaskItem> aClass, Long id) {
     return taskItemDao.findTaskItem(id);
   }
}

DAO:

@Override
@Transactional(propagation = Propagation.REQUIRED)
public void updateTaskItems(List<TaskItem> taskItemToUpdate) {
        for (TaskItem ti : taskItemToUpdate) {
            getHibernateTemplate().update(ti);
        }
}

When I simulate this situation without calling find in RequestFactory everything works ok. The exception is thrown when other transaction changes my object. But how to gets this behavior in RequestFactory? Besides befor every update RequestFactory call find method so select to DB is performed. Next go to DAO layer and hibernate calls exacly the same select query because he checks object version. So one select is duplicated unnecessery, for every updated object!!!

---

RequestFactory sends only diffs (i.e. what you changed on the object, on the client-side), so it needs to apply those diffs to an object on the server-side before calling your service method, and that's why it needs to find the object by its ID.
Also, when you reference an object without modifying it (e.g. you set a property object A to reference object B, object B isn't modified), the same find() method is used; and in this case you probably don't want an optimistic lock error (i.e. baking optimistic lock check into the find() isn't possible).
Optimistic locking is hard to do well, because you then have to handle conflicts (and users don't want to read "someone changed the thing while you were modifying it, so I'm gonna trash your changes and start you over fresh from the newest version").

See http://code.google.com/p/google-web-toolkit/issues/detail?id=6046 about optimistic locking and RequestFactory.