You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Kent Larsson <ke...@gmail.com> on 2009/02/10 09:15:18 UTC

Three tier layered application using Wicket + Spring + Hibernate. How would you handle transactions?

Hi,

I'm thinking about using the **Open Session In View (OSIV)** filter or
interceptor that comes with Spring, as it seems like a convenient way
for me as a developer. If that's what you recommend, do you recommend
using a filter or an interceptor and why?

I'm also wondering how it will mix with **HibernateTemplate** and if I
will loose the ability to mark methods as **@Transactional(readOnly =
true)** etc and thus loose the ability to get some more fine grained
transaction control?

Is there some kind of best practice for how to integrate this kind of
solution with a three tier architecture using Hibernate, Spring and
Wicket?

If I use OSIV I will at least never run into lazy loading exceptions,
on the other hand my transaction will live longer before being able to
commit by being uncommitted in the view as well.

Best regards, Kent

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Three tier layered application using Wicket + Spring + Hibernate. How would you handle transactions?

Posted by James Carman <jc...@carmanconsulting.com>.
Here's the demo code I used for a talk on wicket a while back.  It
includes OSIV and has an example of doing a repository (think DAO)

http://svn.carmanconsulting.com/public/wicket-advanced/trunk


On Tue, Feb 10, 2009 at 3:15 AM, Kent Larsson <ke...@gmail.com> wrote:
> Hi,
>
> I'm thinking about using the **Open Session In View (OSIV)** filter or
> interceptor that comes with Spring, as it seems like a convenient way
> for me as a developer. If that's what you recommend, do you recommend
> using a filter or an interceptor and why?
>
> I'm also wondering how it will mix with **HibernateTemplate** and if I
> will loose the ability to mark methods as **@Transactional(readOnly =
> true)** etc and thus loose the ability to get some more fine grained
> transaction control?
>
> Is there some kind of best practice for how to integrate this kind of
> solution with a three tier architecture using Hibernate, Spring and
> Wicket?
>
> If I use OSIV I will at least never run into lazy loading exceptions,
> on the other hand my transaction will live longer before being able to
> commit by being uncommitted in the view as well.
>
> Best regards, Kent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Three tier layered application using Wicket + Spring + Hibernate. How would you handle transactions?

Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Tue, 10 Feb 2009, Kent Larsson wrote:
> I'm thinking about using the **Open Session In View (OSIV)** filter or
> interceptor that comes with Spring, as it seems like a convenient way
> for me as a developer. If that's what you recommend, do you recommend
> using a filter or an interceptor and why?

What do you mean with an interceptor? If it's Spring-MVC 
specific, it cannot be used with Wicket. A Wicket equivalent 
would be a custom request cycle I suppose.

OSIV servlet filter should work OK.

> I'm also wondering how it will mix with **HibernateTemplate** and if I
> will loose the ability to mark methods as **@Transactional(readOnly =
> true)** etc and thus loose the ability to get some more fine grained
> transaction control?

It depends on what exactly you have the filter do. If you
have the Hibernate transaction manager of Spring, all Spring
*Templates should play nicely with that. Often the filter is
only made to defer closing a session until the end of the
request and transactions must still be started explicitly.
Check out what the filter code does (and how it can be
configured).

> Is there some kind of best practice for how to integrate this kind of
> solution with a three tier architecture using Hibernate, Spring and
> Wicket?

No :)

  http://www.satisfice.com/blog/archives/27

There are a lot of good examples though, the one James
posted is probably good and you should be able to find more
by searching the Wiki and this list in Nabble.

> If I use OSIV I will at least never run into lazy loading exceptions,

Not exactly. You can easily run into lazy loading exceptions
if you store your lazy-loaded objects for more than one
request and then try to access their lazy properties during
and different session than the original one.

> on the other hand my transaction will live longer before being able to
> commit by being uncommitted in the view as well.

What do you mean with this exactly?

Best wishes,
Timo

-- 
Timo Rantalaiho           
Reaktor Innovations Oy    <URL: http://www.ri.fi/ >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org