«

Hi

I'm looking for a simple way to open and close a transaction. (read-only report. spring mvc app)

I need to send the results to a JSP page. I don't need a transaction to span more than one dao.

I arrived at this piece of code:

public List<XDto> load() {
Session session = sessionFactory.openSession();

List<XDto> list = crit.list();

session.close();
return list;

}

And it seems to work!

The results appear correctly on the JSP page. I don't have any lazy loading issues.

The connections are closed because I can click indefinitely on the page.

Does it make sense? (I don't have any Transaction tx = session.beginTransaction()or commit(). )

Is it using non-lazy loading and that explains why the JSP always works?

Ideally I would also remove the sessionFactory.openSession()
and
session.close(). Maybe that's possible with AOP ?
Cheers

"comp.lang.java.programmer" wrote:
> Ideally I would also remove the sessionFactory.openSession()
> and
> session.close(). Maybe that's possible with AOP ?
>

I suggest regular programming over AOP for that.

I don't know quite how you'd use aspect programming to handle that -
the question of session lifetime (although I use EntityManager, it's
similar) is one of how much data you wish to manage and for how long.
You have to signal that somehow; why not with opening and closing a
session?

You do want to encapsulate the use of Session within data-access-layer
types.

--
Lew

On 07-03-2011 20:31, comp.lang.java.programmer wrote:
> I'm looking for a simple way to open and close a transaction. (read-only report. spring mvc app)
>
> I need to send the results to a JSP page. I don't need a transaction to span more than one dao.
>
> I arrived at this piece of code:
>
> public List<XDto> load() {
> Session session = sessionFactory.openSession();
>
> List<XDto> list = crit.list();
>
> session.close();
> return list;
>
> }
>
> And it seems to work!
>
> The results appear correctly on the JSP page. I don't have any lazy loading issues.
>
> The connections are closed because I can click indefinitely on the page.
>
> Does it make sense? (I don't have any Transaction tx = session.beginTransaction()or commit(). )
>
> Is it using non-lazy loading and that explains why the JSP always works?
>
> Ideally I would also remove the sessionFactory.openSession()
> and
> session.close(). Maybe that's possible with AOP ?

Yes - you can do it via AOP.

Or you can use the well-known (but often debated)
session-per-request pattern.

Arne

On 08-03-2011 12:29, Lew wrote:
> "comp.lang.java.programmer" wrote:
>> Ideally I would also remove the sessionFactory.openSession()
>> and
>> session.close(). Maybe that's possible with AOP ?
>>
>
> I suggest regular programming over AOP for that.
>
> I don't know quite how you'd use aspect programming to handle that -
> the question of session lifetime (although I use EntityManager, it's
> similar) is one of how much data you wish to manage and for how long.
> You have to signal that somehow; why not with opening and closing a
> session?

AOP can do the open and close automatically for a large group
of files.

Very convenient.

But requiring some understand from the developers.

> You do want to encapsulate the use of Session within data-access-layer
> types.

session-per-request has a better reputation than session-per-operation.

Arne

On 03/08/2011 07:39 PM, Arne Vajhøj wrote:
> On 08-03-2011 12:29, Lew wrote:
>> "comp.lang.java.programmer" wrote:
>>> Ideally I would also remove the sessionFactory.openSession()
>>> and
>>> session.close(). Maybe that's possible with AOP ?
>>>
>>
>> I suggest regular programming over AOP for that.
>>
>> I don't know quite how you'd use aspect programming to handle that -
>> the question of session lifetime (although I use EntityManager, it's
>> similar) is one of how much data you wish to manage and for how long.
>> You have to signal that somehow; why not with opening and closing a
>> session?
>
> AOP can do the open and close automatically for a large group
> of files.
>
> Very convenient.
>
> But requiring some understand from the developers.
>
>> You do want to encapsulate the use of Session within data-access-layer
>> types.
>
> session-per-request has a better reputation than session-per-operation.

There are sessions and there are sessions. Since the OP mentioned Hibernate
and 'SessionFactory', I took him to mean Hibernate sessions, roughly
equivalent to JPA data managers.

So the open and close operations are not for files.

And the session is not visible to the request.

Unless I'm wrong about what the OP meant.

--
Lew
Honi soit qui mal y pense.

On 03/08/2011 08:46 PM, Lew wrote:
> On 03/08/2011 07:39 PM, Arne Vajhøj wrote:
>> On 08-03-2011 12:29, Lew wrote:
>>> "comp.lang.java.programmer" wrote:
>>>> Ideally I would also remove the sessionFactory.openSession()
>>>> and
>>>> session.close(). Maybe that's possible with AOP ?
>>>>
>>>
>>> I suggest regular programming over AOP for that.
>>>
>>> I don't know quite how you'd use aspect programming to handle that -
>>> the question of session lifetime (although I use EntityManager, it's
>>> similar) is one of how much data you wish to manage and for how long.
>>> You have to signal that somehow; why not with opening and closing a
>>> session?
>>
>> AOP can do the open and close automatically for a large group
>> of files.
>>
>> Very convenient.
>>
>> But requiring some understand from the developers.
>>
>>> You do want to encapsulate the use of Session within data-access-layer
>>> types.
>>
>> session-per-request has a better reputation than session-per-operation.
>
> There are sessions and there are sessions. Since the OP mentioned Hibernate
> and 'SessionFactory', I took him to mean Hibernate sessions, roughly
> equivalent to JPA data managers.
>
> So the open and close operations are not for files.
>
> And the session is not visible to the request.
>
> Unless I'm wrong about what the OP meant.

And the Hibernate session can live as long as the request if that's what you
want; you just have to hide from the request that it is a Hibernate session.

You will note that I did not specify what the session lifetime should be, only
that it is a question. Were I to answer the question it would be thus:

I don't know about "session per request", but with JPA you want an
'EntityManager' around for as long as the data in question needs to be
managed. Same with Hibernate sessions.

I have seen two major errors in this area. One is to have a session open only
long enough to hit the database for a single operation. (I'm guessing that's
what you mean by "session per operation".) The other is to keep a session
open for pretty near forever. Both are stupid.

I suppose "per request" is usually the optimum. I can think of games to play
around that, but for a single rule of thumb you could do worse. Thanks.

--
Lew
Honi soit qui mal y pense.

On 08-03-2011 20:46, Lew wrote:
> On 03/08/2011 07:39 PM, Arne Vajhøj wrote:
>> On 08-03-2011 12:29, Lew wrote:
>>> "comp.lang.java.programmer" wrote:
>>>> Ideally I would also remove the sessionFactory.openSession()
>>>> and
>>>> session.close(). Maybe that's possible with AOP ?
>>>>
>>>
>>> I suggest regular programming over AOP for that.
>>>
>>> I don't know quite how you'd use aspect programming to handle that -
>>> the question of session lifetime (although I use EntityManager, it's
>>> similar) is one of how much data you wish to manage and for how long.
>>> You have to signal that somehow; why not with opening and closing a
>>> session?
>>
>> AOP can do the open and close automatically for a large group
>> of files.
>>
>> Very convenient.
>>
>> But requiring some understand from the developers.
>>
>>> You do want to encapsulate the use of Session within data-access-layer
>>> types.
>>
>> session-per-request has a better reputation than session-per-operation.
>
> There are sessions and there are sessions. Since the OP mentioned
> Hibernate and 'SessionFactory', I took him to mean Hibernate sessions,
> roughly equivalent to JPA data managers.
>
> So the open and close operations are not for files.
>
> And the session is not visible to the request.
>
> Unless I'm wrong about what the OP meant.

I was talking about Hibernate sessions.

Arne

On 08-03-2011 20:56, Lew wrote:
> On 03/08/2011 08:46 PM, Lew wrote:
>> On 03/08/2011 07:39 PM, Arne Vajhøj wrote:
>>> On 08-03-2011 12:29, Lew wrote:
>>>> "comp.lang.java.programmer" wrote:
>>>>> Ideally I would also remove the sessionFactory.openSession()
>>>>> and
>>>>> session.close(). Maybe that's possible with AOP ?
>>>>>
>>>>
>>>> I suggest regular programming over AOP for that.
>>>>
>>>> I don't know quite how you'd use aspect programming to handle that -
>>>> the question of session lifetime (although I use EntityManager, it's
>>>> similar) is one of how much data you wish to manage and for how long.
>>>> You have to signal that somehow; why not with opening and closing a
>>>> session?
>>>
>>> AOP can do the open and close automatically for a large group
>>> of files.
>>>
>>> Very convenient.
>>>
>>> But requiring some understand from the developers.
>>>
>>>> You do want to encapsulate the use of Session within data-access-layer
>>>> types.
>>>
>>> session-per-request has a better reputation than session-per-operation.
>>
>> There are sessions and there are sessions. Since the OP mentioned
>> Hibernate
>> and 'SessionFactory', I took him to mean Hibernate sessions, roughly
>> equivalent to JPA data managers.
>>
>> So the open and close operations are not for files.
>>
>> And the session is not visible to the request.
>>
>> Unless I'm wrong about what the OP meant.
>
> And the Hibernate session can live as long as the request if that's what
> you want; you just have to hide from the request that it is a Hibernate
> session.
>
> You will note that I did not specify what the session lifetime should
> be, only that it is a question. Were I to answer the question it would
> be thus:
>
> I don't know about "session per request", but with JPA you want an
> 'EntityManager' around for as long as the data in question needs to be
> managed. Same with Hibernate sessions.
>
> I have seen two major errors in this area. One is to have a session open
> only long enough to hit the database for a single operation. (I'm
> guessing that's what you mean by "session per operation".) The other is
> to keep a session open for pretty near forever. Both are stupid.
>
> I suppose "per request" is usually the optimum. I can think of games to
> play around that, but for a single rule of thumb you could do worse.

session per request is a well known pattern.

Arne

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 08/03/2011 02:31, comp.lang.java.programmer a écrit :
> Hi
>
> I'm looking for a simple way to open and close a transaction. (read-only report. spring mvc app)

Open-session-in-view pattern is my best choice for that
http://community.jboss.org/wiki/OpenSessioninView

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNd87dAAoJEK8zQvxDY4P96PkH/3ef37UePhB6fIP+xfGDEkdH
gF4jfUfmAv5hZSQ8qaC9+IBqsedD588pCo8egLCEwp4CiWH0e/Krm6WK7OyXqBIA
N27rY2asN1M9eNrF7sbtM3PJE7TyljukniwFC5VvQ4OgmkkAWH 7qVZctVgzvpCXG
ZeNMb/TqcrFQZTkrUtBMYQOmiAw2SuVHSgoC7ro+ZSnwaCqI6AR0fMb4 3TAwxwa8
XRkwtS8G3WpUcwzw44v958vrQ5RFsJwzpD0hBBs7D592lGJzXK V/bfY7fcfYrV54
hK/WIPUfAO0ix4IZoYBwXnlgpabuPGQswQZz9y520mIFJe5fW2I80/qp+c74wW4=
=6k5d
-----END PGP SIGNATURE-----