Hi guys. I would like to ask a question about using hibernate on the desktop. My question would be if there is on the desktop a pattern like ThreadLocal Session/OpenSessionInView on the server side ?

I mean if I use something like that on the desktop it would mean that I have a a single Session bound to the thread for the entire application lifetime. Which I suppose is not a very good practice. Or I should use a different thread for each "action" involving hibernate promoting responsive GUI in the same time ? Please share your thoughts, I could really use some design/architecture oppinions here, even few code sample(s) if I'm not becoming annoying :-)

Thanks. I would have posted it on the beginers thread but I really think it's an architecture question.[/quote]

I can remeber somewone doing a 1 session per desktop on a multithread client using sync on top of the Session.
Search the forum, it was discussed on a long thread.

hello all,

i have a question in the next scenario: there is a set of desktop applications distributed over a LAN, and a central database.

i'm tempted to use hibernate on each workstation to access the central database, however i dont know the implications of the per workstation caching of data.

is it possible to configure 'instances' of hibernate on both sides? i mean having hibernate running on each workstation accesing a central instance of hibernate on the database server??

hope made myself clear, :)

best regards
Gerardo.

My question was not really about synchronization but about how can you make sure you have a session opened when fetching a lazy collection in a desktop app w/o using one single session opened for the entire lifetime of the application.

In a web app you have OpenSessionInViewFilter, I imagine one can do the same thing in a desktop app but then you should "simulate" how the server works, meaning a new thread for each action involving hibernate and for each new thread, a Session bounded in a ThreadLocal.

Thanks.

Third attempt at posting - the session time out must be low, or I'm typing really slow tonight.

I've actually given up using the OpenSessionInView pattern.

I now consider the level of hydration of the object graph as part of the buisness logic and so write services that explicitly set this level. In this manner consumers of the services know what they are getting, and conceptually there is no difference between different methods of consuming or publishing the services. I've found this is the simplist solution, and one that avoids potential hidden lazy initialization errors from biting you.

meaning that for the getOrders() set of orders of a Customer object you have in the service layer a corresponding getOrdersForCustomer(customerId) method ? e.g. CustomerService.getOrdersForCustomer() ?

This is indeed a solution but I was wondering if there isn't another one that would allow me to fully exploit the lazy init collection feature of hibernate...

Hmm, not sure I totally follow the example, but I'll try. If I needed a customer view that required the collection of orders, I would have a service method getCustomer(id) just as if using the OpenSessionInView. But, instead of relying on the OSIV pattern to lazy load he order objects, the service method getCustomer would ensure they are loaded. The actual method used can vary of course between lazy="false", fetch join in HQL, EAGER fetch mode in criteria or explicitly initialzing the orders collection. But, to the view/service consumer nothing changes.