Hi!
Thanks a lot for your answer. I actually want not to update the entity from
the second thread, but just be sure, that the entity I am reading is
up-to-date. And, of course, @Version, optimistic locking does not help me in
this case. In general, let's assume the following scenario.
| * In some stateless bean we have the update() method:
|
| | ...
| | void update() {
| | .....
| | entity.setName("Name");
| | manager.flush();
| | sendJMSNotification();
| | };
| |
| * sendJMSNotification() is sending a message to the rich clients, that
the entity was updated (in my case, the interceptor is doing it)
| * the client is trying to call manager.find(...) from the same stateless
bean, and receives an old data.
|
|
| So, the main question is , if there is a possibility to get postCommit
event? IMHO this is important, because the client may receive the notification
and in theory, the client does NOT have to access the EJB server, but the
database directly. The good example would be a reporting tool, which is
refreshing the data after receiving the notification.
|
| Even If I am implementing manager.lock( entity, LockType.READ ), I think
it does not work properly in this case - after flush() method the lock is gone.
|
| The only workaround I see is to use the direct JDBC calls, but then it
does not make sence to use EJB and Persistence API to work with database.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994144#3994144
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994144
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
