ALRIGHT!
I have Spring set up!
I have Hibernate Template set up!
I have services set up, and DAOs set up!
I have my mappings correct!
I have my struts actions able to see and use the services!
BUT I am getting LazyInitializationExceptions, which is *specifically* what I was trying to avoid having in the first place.
Consider this:
A User object has a SortedSet, rockStars. Contains 0-n RockStar objects. Those boys are big.
I want to lazy-load rockStars.
I have this mapping:
<set
name="rockStars"
table="rockstars"
order-by="name asc"
sort="natural"
inverse="true"
cascade="all-delete-orphan"
>
<key column="userID" />
<one-to-many
class="com.td.bo.game.band.RockStar"
not-found="ignore"
embed-xml="false"
/>
</set>
That should work.
It was my understanding that HibernateTemplate would keep a session open for each User once it passes out of the DAO. But that, apparently, is not the case (according to everything I have read on the Spring forums, like this post).
This sort of eliminates everything I was trying to do in the first place and makes the entire moving to HibernateTemplate pointless. If I can't use lazy-load here, what's the fucking point? I might as well just turn on eager fetching entirely (sub-optimal)
RockStar objects can be large and you only ever need them in the following modes:
1) A list of them (which is then, hopefully, only the fields in the "rockstars" table and not it's assorted child objects, like the EventLog)
2) Everything associated with a single RockStar (the one you're currently connected to)
So WTF? Did I just do all that work getting this shit set up just to be in the exact same place I was before, or am I missing something obvious?
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
jorm- Jörm von Motörhead
- gaijin.com
Comments
I'd have to understand more about how you're setting up your assembly, but I'm guessing you're trying to access the lazy relation in your JSPs and you no longer have an open session. To fix that, you need something like an OpenSessionInViewInterceptor or Filter.
I actually went a different route for this. I turned off lazy loading entirely, and the "large" objects are now fetched by actions as needed.
So, given a User with n+ RockStars, there is no direct way to access the RockStar set from User. Instead, I created a new Service that goes List<RockStar> getRockStarsForUser(u), and is called from ListRockStarsAction. This stuffs the List into the request, which is then sent to the JSPs independently.
For things like, oh, the EventLog, I'll do something similar (getEventLogForRockStar(rs)).
All of our transactions go through org.springframework.transaction.intercep
for the most part and anything that needs db access is done inside one of those methods. Seems like that's the part you're missing. There's other (probably better) ways to establish the session and transactions, but that's probably where you need to focus.
Most of the post you linked seemed to be talking about a three-tiered system where the persisted object was actually being loaded to the client and trying to avoid the network cost of not lazy-loading, so I'm not sure that applies in your case, it seems to be more just session/transaction lifecycle details. (When does the session start, what transactions are in the session, etc.)