-
1. Re: How to avoid implicit database update
gavin.king Jan 28, 2007 12:32 PM (in response to umarzubair)Use an atomic conversation @Begin(flushMode=MANUAL)
-
2. Re: How to avoid implicit database update
umarzubair Jan 29, 2007 1:00 AM (in response to umarzubair)Thanks for your quick reply.
Yes, it worked but I have to call commit or flush explicitly. I am using TransactionManager.
I just want to avoid dirty updates.
For example If I have a conversation based on 2 requests. In first request Application update a data model, and in second request Application calls session.saveOrUpdate method. I just want to update database after second request by Seam Transaction Manager.
Umar -
3. Re: How to avoid implicit database update
umarzubair Jan 29, 2007 8:09 AM (in response to umarzubair)Now I am using your recommendation
@Begin(flushMode=MANUAL) and at end of conversation calling session.flush() explicitly.
Now I have another problem. Suppose 1 conversation has 2 requests.
In request 1, Application fetch a record say 'A' from database.
Before second request, Record 'A' gets updated by some other transaction.
In request 2, Application need to execute same query to find record 'A' again with latest data. HibernateSession does not go into database to find latest values for Record 'A' and it return same record 'A' fetched in request 1.
If I use session.evict(model) in request 1, then request 2 returns latest record from database.
Is there any way to get latest record from database every time without using evict method.
Regards,
Umar -
4. Re: How to avoid implicit database update
gavin.king Jan 29, 2007 8:34 AM (in response to umarzubair)No, you should use optimistic locking, ie. add a @Version attribute to your entity.
-
5. Re: How to avoid implicit database update
umarzubair Jan 29, 2007 8:44 AM (in response to umarzubair)I am already using version element in hbm file.
It does not solve the issue.
Umar -
6. Re: How to avoid implicit database update
gavin.king Jan 29, 2007 8:49 AM (in response to umarzubair)Then you are fine. There is no issue to solve. This is the correct way to process long txns in an online app.