This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Its not very clear what you are doing from your post. Could you explain a little about how you are using Hibernate, specifically: are you looking at the objects within the same Session? When you mention cache, do you mean you are using the second level cache? If so which implementation? [ October 14, 2005: Message edited by: Paul Sturrock ]
hmm, i'm actually not very sure wat caused the problem.
okie, i have a form, where user can choose to save or save&submit. If they choose save, they can search for it and then modify&submit later. once the submitted the form, a date will be inserted into the db.
in my backing bean, i have 3 session.save to save my data into my master table, and then to another 2 tables. for the 2 other tables, i'm inserting more than one record, for master record, only inserting one record.
after that, i commit.
ok, now the problem is, for eg. when i do a search , it'll return all the rows that i've created, lets say 3 rows (row1. row2,row3).
let's say each row has data like this: row 1: (id=1, name=row1, date=null) row 2: (id=2, name=row2, date=null) row 3: (id=3, name=row3, date=null)
when i clicked submit, my date only will be inserted. so let's say i choose row 2 and clicked submit, so i can see that now my data :
i'm editing row 1, not touching row 2, but somehow it will update my row 2 and set it into null values. i checked the log file that found that hibernate actually updating my row 2 but in my code, there's NO PLACE that i'm updating row 2.
it's really very difficult to explain, and i hope u understand what i'm trying to say.
i read some articles and from those articles it seems like it's a caching issue, but they did not provide any solutions to this...
Hibernatye has two possible places data can be cached: in the first level cache (the Session) or the second level cache (some third party cache impleentation). The first level cache is always used. When you open a Session and load an object into it, it is now cached in the Session. you can update this object's properties all you like, its only when the session is flushed or closed (by calling those methods on the session) that the object's properties are persisted to the database.
The second level cache is only ever used if you explicitly add caching declarations to your mapping files. Otherwise it is not used.
So if you open a Session and get your three objects they are now in the first level cache. If you update a property on one of these objects and call save() the value in the first level cache is updated, but the value in the database is unchanged. It is only when you call flush() or close the Session that the update actually happens.
It sounds like you are reading your three objects the second time from a a different Session from that which you first read them without closing your first Session. Is this so?
Joined: May 08, 2005
hmm, wat i did is when i first update the record, i use session.update() and then commit. i check the db and the date is there. but when i update other row, my date from my previous row is gone, but the date exists for my newly added row.
sometimes it's even worst, i update one row and 2-3 other rows will be affected. (date becomes null in db)
i even tried session.flush() to get rid of the cache after i save / update but it doesn't really helps..
i tried session.isDirty() as well and the outcome is still the same.
This list that you're updating...where is that stored? Is this a web application and you store that list in the session to repopulate your page (not a hibernate session, but a web session). Please provide some more information on that front. I think you might be using a stale copy from a list that is not getting updated after you perform an update.
So for example, your client has the list with 4 objects...all have null dates. But when you go to update one of those objects on the server and return to the client, the client still has the same list of 4 objects (it wont be the same object instance). So when you go do another update, guess what, any changes you might have made are overwritten because of your stale object.
But if you are reloading the list after every update, forget everything I have just said.
Joined: May 08, 2005
everything is stored in the database. when i update i update the db. i know the date is there because after i do update i go check the db and the date is there. but when i update another record, and i check the db, my previous updated record, the date becomes NULL.
It does sound like some stale object problem. There is nothing in Hibernate that can cause this, if you are properly flushing/closing the Session (which you must be if you can see the update in the database). I think you will have to show us your code.
Joined: Jun 03, 2005
Originally posted by Jolie Lee: everything is stored in the database. when i update i update the db. i know the date is there because after i do update i go check the db and the date is there. but when i update another record, and i check the db, my previous updated record, the date becomes NULL.
Jolie...we're not saying that the data isn't being stored in the database...I'm sure it is. The problem seems to be that when you go to save another object, you're overwriting your changes with an older copy of the object you had just saved. So your initial save is working fine, but you're just inadvertently saving the object again which is probably not what you want to do.
I think what you need to do is reload the list of objects after every save. It might not be the most optimized solution, but do this just to see if that's the real cause of your problem. This way when you reload the list, you'll get the latest and greatest from the database.
This is the kind of problem that optimistic locking is supposed to solve. Hibernate supports this by means of managed versioning...check that out as well. If you implement this, you should get an error when you try to save a stale copy of your object. So it'll force you to reload your objects once they've been committed to the database.
Joined: May 08, 2005
hi, thks for all the replies.
currently i've minimise the problem with doing session.clear, evict and session.close after i do commit.
y do i say minimise is because the date will still gone after 20++ records being inserted/updated. it's better if compared to last time, every record is affected.
anyway, i'll look at the hibernate versioning for more information.
i also had the same problem: After i updated an entity to new value in SESSION1 and i fetched the same entity afterwards in SESSION2, i got old values. I even checked in my DB after closing SESSION1 that new values are present in my db.
There was one not-nice workaround: when I wanted to read updated data, i opend and commited a transation: session.beginTransaction().commit();
However, in my case the problem was in INNODB settings for mysql database. The default isolation level for INNODB is REPEATABLE READ -- I found it here hibernate forum. The solution is in changing the global transaction isolation level to READ_COMMITTED (2) or SERIALIZABLE (8). Check the java.sql.Connection for these isolation levels.
Put the following in your config.hbm.xml
all the best
PS: do not forget do flush() before closing the session ;-)