Hi,

If I understood well, disconnecting the session w/out closing it preserves the session (cache, etc) only the underlying db connection is closed.

Question is:

Why lazy exception is thrown with a disconnected session? I would expect to get the exception with a _closed_ connection, not with a disconnected one.

TIA,

--steve p.

since you haven't "reconnected" the disconnected session, it is normal

Why is it normal?

I still have an open session. Why do I have to lose my lazy mechanism if I disconnect the session?

humm lazy = load data when you ask (when the detail is needed),
to load the data, hibernate needs to hit the db,
to hit the db, it needs the connection,
to reconnect, you must call session.reconnect().

Hibernate is not going to explicitly take control of the connection as the conceptor has specified session.disconnect() before, it is logic no?

OK, what Hibernate could do is:

1. open a DB connection
2. get the lazy data
3. close the DB connection


Is it so difficult?

You know, checking Hibernate.isInitialized() is cumbersome and Hibernate specific, not transparent.

TIA.

it's your job to manage connexion not hibernate job.
Hibernate is not a connexion management tool...
Do you also want hibernate to manage the transaction for you ?

In your case, i admit it "seems" to be easy, but there are so much use case...

So, you mean that even after the user has explicitly told Hibernate to return the connection, via session.disconnect() or session.close(), Hibernate should disobey the user and fetch a new connection?



No, but I don't think it would be very smart. A good tool should help the user do whatever the user wants, not something else because it thinks it knows better. Overzealous "lets prevent the user from shooting himself in the foot"-design tends to lead to tools that are impossible to use for anything else than the tool designer originally thought it should be used for.

If you're doing some web application and want lazy loading to always work, use the "open session in view" pattern: http://www.hibernate.org/43.html.

I thought a persistence framework _should_ indeed hide/manage my connections, shouldn't it?



Like ...

Anyway, the doc is misleading on this point. It suggests everywhere that you have lazy exceptions when the session is closed, not disconnected.

Example:

"In some application architectures, particularly where the code that accesses data using Hibernate, and the code
that uses it are in different application layers, it can be a problem to ensure that the Session is open when a collection
is initialized."

TIA.

This would be an insane feature. Starting and stopping a new transaction just for a single SQL statement is incredibly nonperformant and destroys transaction isolation.

The persistence layer should certainly NOT demarcate your transactions for you. That is your job.

Well, isn't this also the case with



'Cause the user will have eventually to do this in order to avoid the lazy exception.
And this is Hibernate specific, so the presentation layer is bound to the Hibernate layer...
I am _not_ using a web app and cannot use open-in-session-view pattern or whatever it is called.




The lazy mechanism _is_ implemented by Hibernate, so it should make it transparent as much as possible for the user. The lazy exception is one that gives Hibernate users lots of headaches.

Apart from this, of course the user will have to manage the transactions.

TIA.

If your user has to manage transactions, it should be no problem to manage Sessions too.

Randomly opening and closing connections is just nonsense, if you think about it. Just initalize the collections that have to be displayed in advance inside of session scope, or do reattatching to a session if necessary.

.

My idea was to make the lazy mechanism as transparent as possible for the user... Hibernate is a great framework, but you have to keep in mind lots of 'you can't do this, you can't do that', or 'if you do this you have to do that', etc.



???



This kind of breaks the concept of lazy loading, or loading by demand, doesn't it?

TIA.

I happen to agree with dia100. Here's my argument:

Hibernate states that its architecture "abstracts the application from the underlying JDBC/JTA API and lets Hibernate take care of the details" (Hibernate Reference, section 2.1).

Also, in section 6.5 of the same document, we have: "Collections (other than arrays) may be lazily initialized, meaning they load their state from the database only when the application needs to access it. Initialization happens transparently to the user so the application would not normally need to worry about this".

Ok, now let's analyse my situation here.

When I develop applications, I separate the classes in four layers:

persistence: communicates with the database;

domain: contain the domain objects (beans);

application: implements the application functionality;

view: user interface.

Now, say the view asks the application layer for the "list" functionality. The application calls the persistence layer and retrieves a bunch of domain objects, returning them to the view.

As of now, the view can do anything with the objects, including calling methods that should return collections that are marked as lazy-initialized. And it doesn't make sense that it should ask the persistence to reconnect a session to do that, because the view should not even know what a Session is. It should be oblivious to how the persistence is done.

For me, having to reconnect the session is not transparent initialization, because my application DOES have to worry about it. The problem is that you're saying that Hibernate does something it does not.

I'm not asking Hibernate to control my transactions, I just want to be able to disconnect the Session (to free resources) an be able to, later on, retrieve a collection lazilly without having to explicitly reconnect() something at the persistence layer.

Do I make any sense at all?

Thanks for any replies,

V