You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Boris Horvat <ho...@gmail.com> on 2013/05/13 00:59:36 UTC
Tapestry Hibernate Session usage
Hi all,
I have a question about what should be the best way to use hibernate
session in tapestry.
My environment consists of 2 layers (relevant to this).
The first one would be a group of classes that represent an access point to
a table. For example if I have a table student then I will have a class
DAOHibernateStudent. This class receives Session object in its constructor.
Doing it this way I can separate all of the queries that are available for
that table into its own class.
The second layer is a class called Manager that implements business logic.
This layer has fields that represent different DAOHibernate* classes. They
are all passed down using constructor. This way I can keep my business
logic in a special class which will communicate with different table
using different DAOHibernate* objects
I use @Inject annotation to inject manager into a page
Lets imagine that I want to create a new Student. So my code would call a
Manager's method createStudent(some data) which would then use a few of the
DAO classes to do all sorts of stuff (e.g. create a student, register
subjects for him, assign him a mentor, add him to a student group, send
notification email and so on...).
The problem that I see here is that since all of those DAO classes are
independent I need to use few Session objects as each one will receive its
own session object. So here are my questions.
1. Will every time when someone loads/refreshes/opens the page a new
Manager class be created which will in return create a new DAOHibernate*
objects and each one will receive a new Session object?
2. Is it a good idea to use different session objects for the same
transaction I guess (yea I know that it is not good idea so moving to the
next question)
3. How should this problem be solved? Should I pass new session object
to manager and then pass it as a method parameter to the DAOHibernate*
4. Any general tips about this approach?
Thanks all,
Cheers
--
Sincerely
*Boris Horvat*
Re: Tapestry Hibernate Session usage
Posted by Boris Horvat <ho...@gmail.com>.
Well thanks for help this makes my understating of the tapestry hibernate a
lot better :)
Cheers
On Tue, May 14, 2013 at 4:38 PM, Lance Java <la...@googlemail.com>wrote:
> Questions about the 'magic' hibernate session proxy seem to crop up a bit
> so I've raised a Jira to improve the docs.
>
> https://issues.apache.org/jira/browse/TAP5-2115
>
--
Sincerely
*Boris Horvat*
Re: Tapestry Hibernate Session usage
Posted by Lance Java <la...@googlemail.com>.
Questions about the 'magic' hibernate session proxy seem to crop up a bit
so I've raised a Jira to improve the docs.
https://issues.apache.org/jira/browse/TAP5-2115
Re: Tapestry Hibernate Session usage
Posted by Dmitry Gusev <dm...@gmail.com>.
On Tue, May 14, 2013 at 12:05 AM, Boris Horvat <ho...@gmail.com>wrote:
> Hi Dmitry
>
> Please ignore the naming as I haven't really user he real names here as
> this is just an example (the project also has nothing to do with Students
> but it is easier for the explanations :) ). In all fairness though I do
> prefer to append DAOService in front as it allows me to search for the
> class more easily (If my page, service and domain class all start with
> Student it is annoying to find anything)
>
> The @CommitAfter it is my manager that has this class not the DAO's so I
> guess why use the same approach
>
> As for the constructor and @Inject annotation I know that I can use it but
> in that way I restrain my self to Tapestry (or Spring), which is not the
> case if I use constructor.
>
> I am aware of the God anti pattern and while there is fine line between
> that and my code I dont think I have crossed it as I have more then one
> manager. They represent an area of business logic and basically they are
> place where transaction annotation is put. Still it is something to keep in
> mind I agree.
>
> I think now I understand a bit more about the Session object in Tapestry.
> So yes if it is shard across all of my DAO object that would be what
> the behavior what I need. Do you know any place where I can read a bit
> about it? I am interested it as from what I can see in my code constructor
> is only called once (you also confirmed this) so I was wondering how does
> it switch the Session object each time? You mention it is a proxy so I
> guess that is how it replaces it, right?
>
>
You can read about proxies here:
http://tapestry.apache.org/defining-tapestry-ioc-services.html
http://tapestry.apache.org/defining-tapestry-ioc-services.html#DefiningTapestryIOCServices-DefiningServiceScope
> Thanks for the reply,
>
> Cheers,
> Boris
>
>
> On Mon, May 13, 2013 at 10:09 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >wrote:
>
> > On Mon, May 13, 2013 at 2:59 AM, Boris Horvat <horvat.z.boris@gmail.com
> > >wrote:
> >
> > > Hi all,
> > >
> > >
> > Hi!
> >
> >
> > > I have a question about what should be the best way to use hibernate
> > > session in tapestry.
> > >
> > > My environment consists of 2 layers (relevant to this).
> > >
> > > The first one would be a group of classes that represent an access
> point
> > to
> > > a table. For example if I have a table student then I will have a class
> > > DAOHibernateStudent. This class receives Session object in its
> > constructor.
> > > Doing it this way I can separate all of the queries that are available
> > for
> > > that table into its own class.
> > >
> > >
> > Thats strange naming, I would name the interface as StudentDAO, and
> > implementation as just StudentDAOImpl.
> >
> > Note that you can also @Inject session to your DAO, you don't have to
> pass
> > it through the constructor.
> >
> > Btw, in my projects I never put @CommitAfter annotations in this layer.
> In
> > this case I can do more than one DAO-method-call in a single transaction.
> >
> > The second layer is a class called Manager that implements business
> logic.
> > > This layer has fields that represent different DAOHibernate* classes.
> > They
> > > are all passed down using constructor. This way I can keep my business
> > > logic in a special class which will communicate with different table
> > > using different DAOHibernate* objects
> > >
> > >
> > Again, you don't have to pass DAO instances via constructor, use @Inject.
> >
> > Having one big Manager class looks like God Object anti-pattern to me --
> > http://en.wikipedia.org/wiki/God_object
> >
> > I usually have one Manager class per table, so in it would be named
> > StudentManager in your case.
> >
> > Its okay having multiple different DAO instances to be injected in this
> > ConcreteManager class also, as well as another manager classes if you
> wish.
> >
> > Usually I put most of @CommitAfter annotations on this layer, some of
> them
> > goes to page classes event handlers directly. Depends on use-case.
> >
> > I use @Inject annotation to inject manager into a page
> > >
> > > Lets imagine that I want to create a new Student. So my code would
> call a
> > > Manager's method createStudent(some data) which would then use a few of
> > the
> > > DAO classes to do all sorts of stuff (e.g. create a student, register
> > > subjects for him, assign him a mentor, add him to a student group, send
> > > notification email and so on...).
> > >
> > > The problem that I see here is that since all of those DAO classes are
> > > independent I need to use few Session objects as each one will receive
> > its
> > > own session object. So here are my questions.
> > >
> > >
> > As far as I know in tapestry there is only one instance of Session object
> > per request (at least by default) -- its a per-thread proxy.
> > And this Session instance is shared across all your DAO/Manager
> instances.
> >
> >
> > >
> > > 1. Will every time when someone loads/refreshes/opens the page a new
> > > Manager class be created which will in return create a new
> > DAOHibernate*
> > > objects and each one will receive a new Session object?
> > >
> >
> > There are only two scopes for tapestry services now: SINGLETON and
> > PERTRHEAD
> >
> >
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ScopeConstants.html
> >
> > So if you bind your service via AppModule then by default you declare
> > singleton instance.
> >
> > So only one instance of your Manager/DAO classes will be created and
> > injected to your page instance.
> > Btw, there's also only once instance of your page class will be created
> and
> > shared across all requests.
> >
> > 2. Is it a good idea to use different session objects for the same
> > > transaction I guess (yea I know that it is not good idea so moving
> to
> > > the
> > > next question)
> > >
> >
> > As I said above, you usually have one Session object per request, and its
> > okay.
> >
> > Since you will use single session instance you will have common
> first-level
> > cache for all your request-scoped-queries, which is also good, I think.
> >
> >
> > > 3. How should this problem be solved? Should I pass new session
> object
> >
> > to manager and then pass it as a method parameter to the DAOHibernate*
> > >
> >
> > Leave session management to tapestry and only think about transaction
> > scope, i.e. where to put @CommitAfter annotations.
> >
> > Use @Inject to inject sessions and other tapestry services to your
> classes.
> >
> >
> > > 4. Any general tips about this approach?
> > >
> >
> > Thanks all,
> > >
> > > Cheers
> > >
> > > --
> > > Sincerely
> > > *Boris Horvat*
> > >
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
> >
>
>
>
> --
> Sincerely
> *Boris Horvat*
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tapestry Hibernate Session usage
Posted by Boris Horvat <ho...@gmail.com>.
Hi Dmitry
Please ignore the naming as I haven't really user he real names here as
this is just an example (the project also has nothing to do with Students
but it is easier for the explanations :) ). In all fairness though I do
prefer to append DAOService in front as it allows me to search for the
class more easily (If my page, service and domain class all start with
Student it is annoying to find anything)
The @CommitAfter it is my manager that has this class not the DAO's so I
guess why use the same approach
As for the constructor and @Inject annotation I know that I can use it but
in that way I restrain my self to Tapestry (or Spring), which is not the
case if I use constructor.
I am aware of the God anti pattern and while there is fine line between
that and my code I dont think I have crossed it as I have more then one
manager. They represent an area of business logic and basically they are
place where transaction annotation is put. Still it is something to keep in
mind I agree.
I think now I understand a bit more about the Session object in Tapestry.
So yes if it is shard across all of my DAO object that would be what
the behavior what I need. Do you know any place where I can read a bit
about it? I am interested it as from what I can see in my code constructor
is only called once (you also confirmed this) so I was wondering how does
it switch the Session object each time? You mention it is a proxy so I
guess that is how it replaces it, right?
Thanks for the reply,
Cheers,
Boris
On Mon, May 13, 2013 at 10:09 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> On Mon, May 13, 2013 at 2:59 AM, Boris Horvat <horvat.z.boris@gmail.com
> >wrote:
>
> > Hi all,
> >
> >
> Hi!
>
>
> > I have a question about what should be the best way to use hibernate
> > session in tapestry.
> >
> > My environment consists of 2 layers (relevant to this).
> >
> > The first one would be a group of classes that represent an access point
> to
> > a table. For example if I have a table student then I will have a class
> > DAOHibernateStudent. This class receives Session object in its
> constructor.
> > Doing it this way I can separate all of the queries that are available
> for
> > that table into its own class.
> >
> >
> Thats strange naming, I would name the interface as StudentDAO, and
> implementation as just StudentDAOImpl.
>
> Note that you can also @Inject session to your DAO, you don't have to pass
> it through the constructor.
>
> Btw, in my projects I never put @CommitAfter annotations in this layer. In
> this case I can do more than one DAO-method-call in a single transaction.
>
> The second layer is a class called Manager that implements business logic.
> > This layer has fields that represent different DAOHibernate* classes.
> They
> > are all passed down using constructor. This way I can keep my business
> > logic in a special class which will communicate with different table
> > using different DAOHibernate* objects
> >
> >
> Again, you don't have to pass DAO instances via constructor, use @Inject.
>
> Having one big Manager class looks like God Object anti-pattern to me --
> http://en.wikipedia.org/wiki/God_object
>
> I usually have one Manager class per table, so in it would be named
> StudentManager in your case.
>
> Its okay having multiple different DAO instances to be injected in this
> ConcreteManager class also, as well as another manager classes if you wish.
>
> Usually I put most of @CommitAfter annotations on this layer, some of them
> goes to page classes event handlers directly. Depends on use-case.
>
> I use @Inject annotation to inject manager into a page
> >
> > Lets imagine that I want to create a new Student. So my code would call a
> > Manager's method createStudent(some data) which would then use a few of
> the
> > DAO classes to do all sorts of stuff (e.g. create a student, register
> > subjects for him, assign him a mentor, add him to a student group, send
> > notification email and so on...).
> >
> > The problem that I see here is that since all of those DAO classes are
> > independent I need to use few Session objects as each one will receive
> its
> > own session object. So here are my questions.
> >
> >
> As far as I know in tapestry there is only one instance of Session object
> per request (at least by default) -- its a per-thread proxy.
> And this Session instance is shared across all your DAO/Manager instances.
>
>
> >
> > 1. Will every time when someone loads/refreshes/opens the page a new
> > Manager class be created which will in return create a new
> DAOHibernate*
> > objects and each one will receive a new Session object?
> >
>
> There are only two scopes for tapestry services now: SINGLETON and
> PERTRHEAD
>
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ScopeConstants.html
>
> So if you bind your service via AppModule then by default you declare
> singleton instance.
>
> So only one instance of your Manager/DAO classes will be created and
> injected to your page instance.
> Btw, there's also only once instance of your page class will be created and
> shared across all requests.
>
> 2. Is it a good idea to use different session objects for the same
> > transaction I guess (yea I know that it is not good idea so moving to
> > the
> > next question)
> >
>
> As I said above, you usually have one Session object per request, and its
> okay.
>
> Since you will use single session instance you will have common first-level
> cache for all your request-scoped-queries, which is also good, I think.
>
>
> > 3. How should this problem be solved? Should I pass new session object
>
> to manager and then pass it as a method parameter to the DAOHibernate*
> >
>
> Leave session management to tapestry and only think about transaction
> scope, i.e. where to put @CommitAfter annotations.
>
> Use @Inject to inject sessions and other tapestry services to your classes.
>
>
> > 4. Any general tips about this approach?
> >
>
> Thanks all,
> >
> > Cheers
> >
> > --
> > Sincerely
> > *Boris Horvat*
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Sincerely
*Boris Horvat*
Re: Tapestry Hibernate Session usage
Posted by Dmitry Gusev <dm...@gmail.com>.
On Mon, May 13, 2013 at 2:59 AM, Boris Horvat <ho...@gmail.com>wrote:
> Hi all,
>
>
Hi!
> I have a question about what should be the best way to use hibernate
> session in tapestry.
>
> My environment consists of 2 layers (relevant to this).
>
> The first one would be a group of classes that represent an access point to
> a table. For example if I have a table student then I will have a class
> DAOHibernateStudent. This class receives Session object in its constructor.
> Doing it this way I can separate all of the queries that are available for
> that table into its own class.
>
>
Thats strange naming, I would name the interface as StudentDAO, and
implementation as just StudentDAOImpl.
Note that you can also @Inject session to your DAO, you don't have to pass
it through the constructor.
Btw, in my projects I never put @CommitAfter annotations in this layer. In
this case I can do more than one DAO-method-call in a single transaction.
The second layer is a class called Manager that implements business logic.
> This layer has fields that represent different DAOHibernate* classes. They
> are all passed down using constructor. This way I can keep my business
> logic in a special class which will communicate with different table
> using different DAOHibernate* objects
>
>
Again, you don't have to pass DAO instances via constructor, use @Inject.
Having one big Manager class looks like God Object anti-pattern to me --
http://en.wikipedia.org/wiki/God_object
I usually have one Manager class per table, so in it would be named
StudentManager in your case.
Its okay having multiple different DAO instances to be injected in this
ConcreteManager class also, as well as another manager classes if you wish.
Usually I put most of @CommitAfter annotations on this layer, some of them
goes to page classes event handlers directly. Depends on use-case.
I use @Inject annotation to inject manager into a page
>
> Lets imagine that I want to create a new Student. So my code would call a
> Manager's method createStudent(some data) which would then use a few of the
> DAO classes to do all sorts of stuff (e.g. create a student, register
> subjects for him, assign him a mentor, add him to a student group, send
> notification email and so on...).
>
> The problem that I see here is that since all of those DAO classes are
> independent I need to use few Session objects as each one will receive its
> own session object. So here are my questions.
>
>
As far as I know in tapestry there is only one instance of Session object
per request (at least by default) -- its a per-thread proxy.
And this Session instance is shared across all your DAO/Manager instances.
>
> 1. Will every time when someone loads/refreshes/opens the page a new
> Manager class be created which will in return create a new DAOHibernate*
> objects and each one will receive a new Session object?
>
There are only two scopes for tapestry services now: SINGLETON and PERTRHEAD
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ScopeConstants.html
So if you bind your service via AppModule then by default you declare
singleton instance.
So only one instance of your Manager/DAO classes will be created and
injected to your page instance.
Btw, there's also only once instance of your page class will be created and
shared across all requests.
2. Is it a good idea to use different session objects for the same
> transaction I guess (yea I know that it is not good idea so moving to
> the
> next question)
>
As I said above, you usually have one Session object per request, and its
okay.
Since you will use single session instance you will have common first-level
cache for all your request-scoped-queries, which is also good, I think.
> 3. How should this problem be solved? Should I pass new session object
to manager and then pass it as a method parameter to the DAOHibernate*
>
Leave session management to tapestry and only think about transaction
scope, i.e. where to put @CommitAfter annotations.
Use @Inject to inject sessions and other tapestry services to your classes.
> 4. Any general tips about this approach?
>
Thanks all,
>
> Cheers
>
> --
> Sincerely
> *Boris Horvat*
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com