spring hibernate simple dao JSP

Discussion in 'Java' started by comp.lang.java.programmer, Mar 8, 2011.

  1. 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, Mar 8, 2011
    #1
    1. Advertising

  2. comp.lang.java.programmer

    Lew Guest

    "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
    Lew, Mar 8, 2011
    #2
    1. Advertising

  3. comp.lang.java.programmer

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Mar 9, 2011
    #3
  4. comp.lang.java.programmer

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Mar 9, 2011
    #4
  5. comp.lang.java.programmer

    Lew Guest

    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.
    Lew, Mar 9, 2011
    #5
  6. comp.lang.java.programmer

    Lew Guest

    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.
    Lew, Mar 9, 2011
    #6
  7. 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
    Arne Vajhøj, Mar 9, 2011
    #7
  8. 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
    Arne Vajhøj, Mar 9, 2011
    #8
  9. comp.lang.java.programmer

    Aéris Guest

    -----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
    N27rY2asN1M9eNrF7sbtM3PJE7TyljukniwFC5VvQ4OgmkkAWH7qVZctVgzvpCXG
    ZeNMb/TqcrFQZTkrUtBMYQOmiAw2SuVHSgoC7ro+ZSnwaCqI6AR0fMb43TAwxwa8
    XRkwtS8G3WpUcwzw44v958vrQ5RFsJwzpD0hBBs7D592lGJzXKV/bfY7fcfYrV54
    hK/WIPUfAO0ix4IZoYBwXnlgpabuPGQswQZz9y520mIFJe5fW2I80/qp+c74wW4=
    =6k5d
    -----END PGP SIGNATURE-----
    Aéris, Mar 9, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    647
  2. Rhino
    Replies:
    2
    Views:
    6,158
    James McGill
    Feb 24, 2006
  3. rmn190
    Replies:
    2
    Views:
    2,339
    Arne Vajhøj
    Jan 10, 2008
  4. Amit Jain
    Replies:
    7
    Views:
    3,270
    Amit Jain
    Apr 27, 2009
  5. Navneet Mathpal

    Spring DAO accessing database

    Navneet Mathpal, Mar 1, 2014, in forum: Java
    Replies:
    2
    Views:
    103
    Jeff Higgins
    Mar 2, 2014
Loading...

Share This Page