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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...