Jan 30th, 2007, 05:53 PM
OSIV + Hibernate 3 + Lazy Loading cannot get workaround
as far as I have read here, if you receive LazyInitializationExceptions with OSIV Filter and Hibernate, because you store entities in the HTTP Session, the way to prevent this is to LOCK() the entity.
Well my problem is now how to get the hibernate session which is necessary to lock the entity?
can give me the hibernate session. So how can I do that?
thanks in advance
Jan 31st, 2007, 02:54 AM
Are you working with HibernateTemplate? If so there is HibernateTemplate.lock(..), or if you really want access to the Session, Hibernate.execute(HibernateCallback).
Mar 18th, 2007, 02:51 PM
My workaround is just to prevent storing hibernate proxies (lazy-loading enabled objects) in session. I now create a plain DTO for such purposes.
The proxies and necessary Hibernate session are really one reason for me to ditch Hibernate in the future. I really prefer technologies that do not impose implicit restrictions on my application. What really screws me up is that everywhere you can read that Hibernate is about light-weight POJO persistence. But sorry, If I cannot use my POJOs as POJOs, it's not that light-weight anymore.
Mar 19th, 2007, 07:42 AM
I'm sorry but I really don't understand what your point is. Does Hibernate let you work with POJOs, YES. Has Hibernate saved me hours of writing boilerplate code, YES. If you could explain your issues, I'm sure there's a simple answer.
Mar 20th, 2007, 06:01 PM
ok I'm far from being an HB expert but I have encountered two
big problems (which are indirectly described in my previous post)
and I see no way of a nice solution.
I will briefly describe them:
A service saves some data with several method invocations say
Around this I have a JTA transaction which sets (I don't know why) the Flush mode to AUTO. Let's say entityB is an object graph with some transient objects. Sometimes I had the problem that hibernate flushes the session
and I received a TransientWhateverException. The problem is that I
could not find out why HB sometimes tried to flush the session.
In practise this makes the AUTO mode unusable for me.
I tried to figure out clearly when and why HB would issue a flush
but I could not find sufficient documentation. I dont like such pseudo intelligent functionality. I think only the programmer knows and should
tell is persistence layer when to do something like a flush.
1.1) Why is there something like a TransientWhateverException anyway.
I consider this paternalism of the programmer. If I have attached an unsaved
relation to another persisted object and then decide not to save it... fine!.
Why on earth HB throws an exception in that situation. Maximum I would
do is to log a warning.
2.) Simple situation: You hava a persisted entity and a HTML form for that entity. Now you want to store that object in a session because the user
might make some modification on that form and after some reqeust/response
cycles, the user wants to save his input. Problem is that I'm not able to save this entity if it is a HB proxy because it has a stale HB session attached to it.
I'm not even able to lazy-load any data after the request in which the entity has been loaded. To me, such an entity has noting to do with a POJO because it cannot be used as a POJO. I know what you want to tell me now: It is possible to detatch and attach objects from the session -- right? But sorry, this functionality is a joke as it cannot deal with object graphs as far as I know. Or is there any other way to realize this use case with HB?
This is my sad HB experience so far.
It happened _sometimes_
Mar 21st, 2007, 07:48 AM
#1. When does the session flush?
#2. Don't want an association saved.
It's natural for it to try and save associations and complain when there is a problem, I'd be worried if it didn't. What you seem to be after is to tell the cascade to ignore if transient.
#3. Want to work with the REAL object.
Initialise the proxy, don't work with it. If you want associations lazy loaded, it makes sense you have to be attached to the session. If you don't want to be then eagerly load the association. If you weren't working with Hibernate you'd have to do this anyway.
Mar 23rd, 2007, 05:30 AM
Ok, that sheds some light on HBs behaviour, thanks
Ok, but I think this is a matter of taste. I know what I do
and don't care if something I want to discard intentionally is not saved.
can you please detail on "Initialise the proxy, don't work with it"
Do you suggest to use DTOs or something in case I want to use such objects in an HTTP session?
Mar 23rd, 2007, 07:30 AM
#1. Nice, sorted
#2. I completely understand what you are saying here. I'm not sure if there's a way to deal with this or not, have to have a think
#3. Some fetch operations (e.g. load) might not give you the real object but a Hibernate proxy. If you don't want this then after the fetch call HibernateTemplate.initialize(..) to give you the real object. If you want to have the associations eagerly fetched you can do this in HSQL or QBC. If you want to work with DTOs then just copy the state from one object to the other within the scope of the Hibernate Session
Apr 4th, 2007, 07:39 AM
Re Karl's point 3, if you always want an association to be returned, consider putting a fetch="join" on the Hibernate mapping. This of course makes it non-lazy, but you might always want this, even though it could be considered a dredge in certain cases.
Originally Posted by karldmoore
Apr 4th, 2007, 12:13 PM