Hibernate version: 3.2.5 ga

Mapping documents:



Goodmornign, I have a problem with the classes shown in the mapping.

The architecture of my apllication requires that hibernate is only responsible of getting objects from the database, instead insert and update operations are performed by direct sql on the database.
This is a requirement and can not be changed.

When an update is performed, I have to remove the updated object from the cache.
I used the session.evict(object) and I had no problems.

When I wrote the update of the photo field, instead, I experienced some problems:
I update the blob field in the database, call the Session.evict on the updated object.
But, when I access to the user photo the behaviour is strange: some times the new photo is presented, some others time the old one. It seems without logic. The old one, the new one, then the new one and the old one and so on.

Where is my mistake?
I can suppose that the object is not really removed from the session, but why?

I hope you can help me.
Thank you very much.

configure Hibernate to not use caching...
This will of course negatively affect performance.

The second level cache for these object is already not enabled.

The problem I think is related to the Session, an so to the first level cache.

Did you find a solution to this? I seem to have caching problems too (I load up the data in my application, then do a direct query into mysql to update something and the update doesn't show in the application for a while).

Edit: Nevermind, my problem was solved by doing a transaction.commit(); even though I never modified anything.

I am having the same issues. I started facing this issue when I upgraded to the latest version of hibernate ie. 3.2.5. This was not a problem with the previous version. The only difference in my case is that I updated the data using hibernate and when the page is refreshed the old or previous value of the fiels is displayed. I do a commit after the update but still the old data is displayed. Any thoughts.

Thanks

Even I am facing the same problem - the values fetched back in the User Interface are not the latest ones, after updation.
The updated values are fetched to the UI, but not always, generally after 2/3 updates, the values being fetched are the stale values.
According to me, this is due to the session-cache.

Can anyone suggest any workaround...

Thanks,
Devesh.

Devesh,
Let me know if you find a solution to the problem.

Try if Session.clear() solves the problem. If so, then you have a problem with first level cache which should be addressed case by case.

Hi

I've had this same problem: due to outside factors, Hibernate can only be used in constrained ways, and a lot of special sql must be overridden in order to play by the required rules.

I'm starting to come to the conclusion that it might be better to *NOT* use Hibernate when you have to cripple/modify its default behavior too much. As you can see, there are so many other problems (caching, session issues, lazy initialization, mapping/config errors) that cause Hibernate to become more of a hindrance than help.

IMO, using something like JdbcTemplate from Spring or other Jdbc helper libraries is sometimes more straight-forward than trying to fit Hibernate into a project where it can't be used as designed.

Don't get me wrong - I would never go back to Jdbc on any project where I had full control of both the database and object models, but on legacy projects, especially those that have been taped-up and hacked to hell, Hibernate may not be the way to go...

Bill

I have been through a number of workarounds and have come up with the following Findings, to the Hibernate Cache problems:

1) Its not possible in Hibernate to do something like - "find all records matching such-and-such criteria. If we already have this object in memory, update its state from the results." You really have two choices in Hibernate when doing searches:
a) using LockMode.NONE, which simply ignores any changes made to records it receives that are already in the session cache, or
b) using some other LockMode (READ or WRITE), which will throw a fatal exception if one or more of the objects received have been changed from the in-memory session cache.

2) There's another issue with the way the Indexed Lists(ie. java.util.List) are handled in Hibernate, with an integer index value for each item, inserting, reordering, or deleting an item in an indexed list will cause ALL the objects below it in the list to get a new index value, and updates the version column. This makes it extremely likely that you'll get stale data on the client, because even if an item has not been changed, if some other user deleted an item in the same list, it will show up as having been modified and not deleted.

3) session.refresh() is OK for telling HIbernate to update the in-memory contents of the object, but there are three problems with it.
a) There is a bug with cascading refreshes, so that if you try to refresh an object that has a to-many association where one of the items in the collection has been removed on the server, it will fail with an exception. This is not too bad, you can solve it by disabling cascades and doing it all manually.
b) A minor point, which is that the docs recommend not using this method. They don't say why.
c) Hibernate does an immediate SQL fetch for each refreshed object, so it is very inefficient to refresh batches of objects, and since there is no refreshing query capability (see first point), there is no efficient way that I can see to refresh a list of items. This is especially bad with the prior point about sort ordering, because it means that I'm much more likely to need to have to refresh all the items in a list.

These are some real Heart-Shaking findings. I m still looking for a good solution, and would post it real soon.

Thanks,
------------------------
Devesh Chanchlani.
------------------------
The best ammunition is a load of aimbition fired with efforts towards a definite goal !!!

I have also resolved my issues. I am using oracle as a back end. I removed the property initial-limit from the datasources file and the applicaiton seems to be working

Can you please explain in detail how?!

I am a bit confused regarding what you say...
By doing away with the "initial-limit" property, are you removing the connection pooling (If I am getting it right), and the problem is resolved ??
If not, can you please post your code ...

The problem has been resolved. I am not sure why and I dont have a reason why removing this property from the datasource file resolved the problem.

Oracle uses initial-limit to open a certain number of connections when the application first comes up. The value of this property is numberic. For example if the value is set to 5, then when a oracle application is started it will open 5 connections to the database. This is a way of decreasing the ramp time of the application.

Again, I cannot think of a logical reason why the issue is resolved.