You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Anthony Fox <an...@gmail.com> on 2006/02/22 14:12:11 UTC
hibernate detached objects as persistent page properties
Hi,
I have an application that has a lot of hibernate detached objects
(with lazy loaded collections) that are persistent page properties.
What are best practices for reattaching these detached objects while
maintaining a clean separation of layers? I have my implementation
specific persistence layer separated into DAOs, a service layer, and
the tapestry ui layer. I would like to keep tapestry independent of
the persistence layer. I am using the OpenSessionInView pattern to
open a new hibernate session for each web request. However, I can't
determine a clean way to reattach all the hibernate detached objects
at the beginning of each web request. I've noticed that some people
use pageBeginRender() to reattach objects, but I don't want to expose
my tapestry code to the persistence implementation. An interceptor or
filter or something that separated the ui layer from being aware of
the persistence layer would be ideal. How have others dealt with this
issue?
Thanks,
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate detached objects as persistent page properties
Posted by James Carman <ja...@carmanconsulting.com>.
What I did for that was store the userId in an ASO and then use a threaded
HiveMind service (which can look up the ASO through the
ApplicationStateManager) to query for the User object as it is needed (lazy
initialization) based on the userId stored in the ASO...
<contribution configuration-id="tapestry.state.ApplicationObjects">
<state-object name="UserSession" scope="session">
<create-instance class="com.martialware.web.state.UserSession"/>
</state-object>
</contribution>
<service-point id="SecurityContext"
interface="com.martialware.web.service.SecurityContext">
<invoke-factory model="threaded">
<construct
class="com.martialware.web.service.impl.SecurityContextImpl"/>
</invoke-factory>
</service-point>
public class SecurityContextImpl implements SecurityContext
{
private ApplicationStateManager stateManager;
private SecurityService securityService;
private UserRepository userRepository;
private User user;
public void authenticate( String userName, String password ) throws
InvalidPasswordException,
InvalidUserIdException
{
securityService.authenticate( userName, password );
getUserSession().setUserId( userName );
}
public boolean isAuthenticated()
{
final UserSession userSession = getUserSession();
return userSession.getUserId() != null;
}
public void logout()
{
getUserSession().setUserId( null );
}
public User getUser()
{
if( user == null )
{
if( isAuthenticated() )
{
user = userRepository.getUserByUserId(
getUserSession().getUserId() );
}
}
return user;
}
private UserSession getUserSession()
{
final UserSession userSession = ( UserSession ) stateManager.get(
UserSession.NAME );
return userSession;
}
public void setUserRepository( UserRepository userRepository )
{
this.userRepository = userRepository;
}
public void setSecurityService( SecurityService securityService )
{
this.securityService = securityService;
}
public void setStateManager( ApplicationStateManager stateManager )
{
this.stateManager = stateManager;
}
}
-----Original Message-----
From: Anthony Fox [mailto:anthonyfox@gmail.com]
Sent: Thursday, February 23, 2006 8:57 AM
To: Tapestry users
Subject: Re: hibernate detached objects as persistent page properties
Thanks for the code. I'll take a look and see if I can incorporate
this in my application.
One further question, how have people dealt with detached hibernate
objects in the session? In my case, which I imagine is a common case
for a lot of people, after the user has authenticated, I store the
User object in my Visit object. The user object is a hibernate
detached entity. As the user performs actions on the site, I update
the user object including updating lazy loaded collections that map
the user object to other tables. I suppose I have to reattach the
User object for each request but this doesn't seem terribly efficient.
What have others done?
On 2/22/06, James Carman <ja...@carmanconsulting.com> wrote:
> Oh, forgot to mention on thing (and that's what this whole thread is all
> about). There's a new page persistence strategy implemented in there too.
> Just declare your page properties as stored using "entity" like this...
>
> @Persist("entity")
> public abstract Account getAccount();
>
> And, Tapernate will store the object (it has to be a single object at the
> moment; it doesn't support collections) in the session using only its
> identity and automatically reconstitute it when you come back each time.
> Now, if the object is an entity object, but it isn't persistent yet, it'll
> just keep it in the session as-is without translating it into its
identity.
> Hope this stuff works for you guys! Let me know if I can help with
> anything.
>
>
> -----Original Message-----
> From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
> Andreas Bulling
> Sent: Wednesday, February 22, 2006 1:33 PM
> To: Tapestry users
> Subject: Re: hibernate detached objects as persistent page properties
>
> On 22. Feb 2006 - 13:30:00, James Carman wrote:
> | Okay, folks. I've abstracted out the Hibernate/Tapestry stuff into its
> own
> | project called "Tapernate." You can download the source and build it
> | yourself (the libs are there for you) from SVN:
> |
> | http://www.carmanconsulting.com/svn/public/tapernate/trunk
>
> *Running to fire up the browser... ;)*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Anthony Fox <an...@gmail.com>.
Thanks for the code. I'll take a look and see if I can incorporate
this in my application.
One further question, how have people dealt with detached hibernate
objects in the session? In my case, which I imagine is a common case
for a lot of people, after the user has authenticated, I store the
User object in my Visit object. The user object is a hibernate
detached entity. As the user performs actions on the site, I update
the user object including updating lazy loaded collections that map
the user object to other tables. I suppose I have to reattach the
User object for each request but this doesn't seem terribly efficient.
What have others done?
On 2/22/06, James Carman <ja...@carmanconsulting.com> wrote:
> Oh, forgot to mention on thing (and that's what this whole thread is all
> about). There's a new page persistence strategy implemented in there too.
> Just declare your page properties as stored using "entity" like this...
>
> @Persist("entity")
> public abstract Account getAccount();
>
> And, Tapernate will store the object (it has to be a single object at the
> moment; it doesn't support collections) in the session using only its
> identity and automatically reconstitute it when you come back each time.
> Now, if the object is an entity object, but it isn't persistent yet, it'll
> just keep it in the session as-is without translating it into its identity.
> Hope this stuff works for you guys! Let me know if I can help with
> anything.
>
>
> -----Original Message-----
> From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
> Andreas Bulling
> Sent: Wednesday, February 22, 2006 1:33 PM
> To: Tapestry users
> Subject: Re: hibernate detached objects as persistent page properties
>
> On 22. Feb 2006 - 13:30:00, James Carman wrote:
> | Okay, folks. I've abstracted out the Hibernate/Tapestry stuff into its
> own
> | project called "Tapernate." You can download the source and build it
> | yourself (the libs are there for you) from SVN:
> |
> | http://www.carmanconsulting.com/svn/public/tapernate/trunk
>
> *Running to fire up the browser... ;)*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate detached objects as persistent page properties
Posted by James Carman <ja...@carmanconsulting.com>.
Oh, forgot to mention on thing (and that's what this whole thread is all
about). There's a new page persistence strategy implemented in there too.
Just declare your page properties as stored using "entity" like this...
@Persist("entity")
public abstract Account getAccount();
And, Tapernate will store the object (it has to be a single object at the
moment; it doesn't support collections) in the session using only its
identity and automatically reconstitute it when you come back each time.
Now, if the object is an entity object, but it isn't persistent yet, it'll
just keep it in the session as-is without translating it into its identity.
Hope this stuff works for you guys! Let me know if I can help with
anything.
-----Original Message-----
From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
Andreas Bulling
Sent: Wednesday, February 22, 2006 1:33 PM
To: Tapestry users
Subject: Re: hibernate detached objects as persistent page properties
On 22. Feb 2006 - 13:30:00, James Carman wrote:
| Okay, folks. I've abstracted out the Hibernate/Tapestry stuff into its
own
| project called "Tapernate." You can download the source and build it
| yourself (the libs are there for you) from SVN:
|
| http://www.carmanconsulting.com/svn/public/tapernate/trunk
*Running to fire up the browser... ;)*
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Andreas Bulling <sp...@phoenix.hadiko.de>.
On 22. Feb 2006 - 13:30:00, James Carman wrote:
| Okay, folks. I've abstracted out the Hibernate/Tapestry stuff into its own
| project called "Tapernate." You can download the source and build it
| yourself (the libs are there for you) from SVN:
|
| http://www.carmanconsulting.com/svn/public/tapernate/trunk
*Running to fire up the browser... ;)*
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Andreas Bulling <sp...@phoenix.hadiko.de>.
On 22. Feb 2006 - 12:51:19, James Carman wrote:
| Hold your horses. I've almost got my stuff set up in SVN for you all to
| check out. I'm creating a project called "Tapernate" (cheesey, I know).
I nearly can't wait any longer and I'm counting the minutes :-)
Wooo, when I posted my question one week ago I couldn't imagine that
there would be such a great public interest - especially on a Tapestry
mailinglist. ;)
Seems as if I should definitely create a page describing the setup procedure
afterwards. Perhaps I could also put your sample app there, what do you think?
Sincerly,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Anthony Fox <an...@gmail.com>.
I don't want to expose the hibernate session to tapestry pages and
components. I would rather keep the ui layer unaware of detached
objects or the mechanism of reattaching those objects or even whether
an object is detached or not. I'm looking for a way in which I can
reattach the objects transparently and allow my tapestry code to
simply use those objects as is.
On 2/22/06, Konstantin Ignatyev <kg...@yahoo.com> wrote:
> You could do reattach objects with hibernateSession.lock( object, LockMode.NONE), but I suggest explicit reattaching with session.merge( object ).
> Explicit merging is better IMO because easily allows "wizard"-like multi iteration editing of an object and then persisting all the changes if desired.
>
> With automatic reattaching all the changes will be persisted as user proceeds and it makes harder to cancel all those changes....
>
> Anthony Fox <an...@gmail.com> wrote: I have considered a similar solution as I use Spring as well.
> However, I was looking for a way to not have to _explicitly_ reattach
> objects. Rather, I would like all persistent detached objects in the
> session's context to reattach automatically. A filter or interceptor
> with knowledge of what objects are hibernate detached objects and
> reattached them automatically would be ideal. This would ease further
> development as adding new persistent properties to pages wouldn't need
> the additional step of adding these properties to the list of
> properties to reattach at pageRender time. Have you considered or
> seen a solution like the one I have described?
>
> On 2/22/06, Shawn Church wrote:
> > I'm doing this in several applications. I normally use Spring also, but
> > that is not really necessary. Tapestry isn't aware of the persistence
> > implementation, but it does have to explicitly attach (and occasionally
> > merge or evict) detached objects. Since I reference my DAO services in
> > my Tapestry pages already, it seemed appropriate to create a
> > "HibernateService" and "HibernateLegacyService" (I probably should have
> > named them something more generic) with public methods supporting
> > attach, merge, and evict. I have to support multiple, unrelated
> > databases, hence the multiple session-management implementations. I
> > only attach in pageBeginRender, although I occasionally have to merge or
> > evict in my form listener.
> >
> > I believe Tapestry is best suited to working with detached objects (and
> > this method is one which is recommended by the Hibernate team), rather
> > than storing IDs and reloading. In my case especially where I have a
> > lot of composite keys, passing IDs around would be a hack. Having the
> > detached object available to Tapestry makes it very nice and seamless
> > when I need access to collections or other objects within that object.
> >
> > I don't experience lazy initialization exceptions any more (unless I've
> > done something really wrong), but NonUniqueObjectExceptions can creep in
> > if for example I try to load an object which happens to already have
> > been loaded within the same session within a collection of a parent
> > object. This is again often the result of me doing something stupid,
> > but there a few (rare in my case) legitimate instances where this is
> > needed. In this case, I take care to first evict (or merge if
> > appropriate) the duplicate object.
> >
> > Shawn
> >
> > Quoting Anthony Fox :
> >
> > > Hi,
> > >
> > > I have an application that has a lot of hibernate detached objects
> > > (with lazy loaded collections) that are persistent page properties.
> > > What are best practices for reattaching these detached objects while
> > > maintaining a clean separation of layers? I have my implementation
> > > specific persistence layer separated into DAOs, a service layer, and
> > > the tapestry ui layer. I would like to keep tapestry independent of
> > > the persistence layer. I am using the OpenSessionInView pattern to
> > > open a new hibernate session for each web request. However, I can't
> > > determine a clean way to reattach all the hibernate detached objects
> > > at the beginning of each web request. I've noticed that some people
> > > use pageBeginRender() to reattach objects, but I don't want to
> > > expose
> > > my tapestry code to the persistence implementation. An interceptor
> > > or
> > > filter or something that separated the ui layer from being aware of
> > > the persistence layer would be ideal. How have others dealt with
> > > this
> > > issue?
> > >
> > > Thanks,
> > > Anthony
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate detached objects as persistent page properties
Posted by James Carman <ja...@carmanconsulting.com>.
Hold your horses. I've almost got my stuff set up in SVN for you all to
check out. I'm creating a project called "Tapernate" (cheesey, I know).
-----Original Message-----
From: Anthony Fox [mailto:anthonyfox@gmail.com]
Sent: Wednesday, February 22, 2006 12:43 PM
To: Tapestry users
Subject: Re: hibernate detached objects as persistent page properties
I have considered a similar solution as I use Spring as well.
However, I was looking for a way to not have to _explicitly_ reattach
objects. Rather, I would like all persistent detached objects in the
session's context to reattach automatically. A filter or interceptor
with knowledge of what objects are hibernate detached objects and
reattached them automatically would be ideal. This would ease further
development as adding new persistent properties to pages wouldn't need
the additional step of adding these properties to the list of
properties to reattach at pageRender time. Have you considered or
seen a solution like the one I have described?
On 2/22/06, Shawn Church <sh...@boxity.com> wrote:
> I'm doing this in several applications. I normally use Spring also, but
> that is not really necessary. Tapestry isn't aware of the persistence
> implementation, but it does have to explicitly attach (and occasionally
> merge or evict) detached objects. Since I reference my DAO services in
> my Tapestry pages already, it seemed appropriate to create a
> "HibernateService" and "HibernateLegacyService" (I probably should have
> named them something more generic) with public methods supporting
> attach, merge, and evict. I have to support multiple, unrelated
> databases, hence the multiple session-management implementations. I
> only attach in pageBeginRender, although I occasionally have to merge or
> evict in my form listener.
>
> I believe Tapestry is best suited to working with detached objects (and
> this method is one which is recommended by the Hibernate team), rather
> than storing IDs and reloading. In my case especially where I have a
> lot of composite keys, passing IDs around would be a hack. Having the
> detached object available to Tapestry makes it very nice and seamless
> when I need access to collections or other objects within that object.
>
> I don't experience lazy initialization exceptions any more (unless I've
> done something really wrong), but NonUniqueObjectExceptions can creep in
> if for example I try to load an object which happens to already have
> been loaded within the same session within a collection of a parent
> object. This is again often the result of me doing something stupid,
> but there a few (rare in my case) legitimate instances where this is
> needed. In this case, I take care to first evict (or merge if
> appropriate) the duplicate object.
>
> Shawn
>
> Quoting Anthony Fox <an...@gmail.com>:
>
> > Hi,
> >
> > I have an application that has a lot of hibernate detached objects
> > (with lazy loaded collections) that are persistent page properties.
> > What are best practices for reattaching these detached objects while
> > maintaining a clean separation of layers? I have my implementation
> > specific persistence layer separated into DAOs, a service layer, and
> > the tapestry ui layer. I would like to keep tapestry independent of
> > the persistence layer. I am using the OpenSessionInView pattern to
> > open a new hibernate session for each web request. However, I can't
> > determine a clean way to reattach all the hibernate detached objects
> > at the beginning of each web request. I've noticed that some people
> > use pageBeginRender() to reattach objects, but I don't want to
> > expose
> > my tapestry code to the persistence implementation. An interceptor
> > or
> > filter or something that separated the ui layer from being aware of
> > the persistence layer would be ideal. How have others dealt with
> > this
> > issue?
> >
> > Thanks,
> > Anthony
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate detached objects as persistent page properties
Posted by James Carman <ja...@carmanconsulting.com>.
Okay, folks. I've abstracted out the Hibernate/Tapestry stuff into its own
project called "Tapernate." You can download the source and build it
yourself (the libs are there for you) from SVN:
http://www.carmanconsulting.com/svn/public/tapernate/trunk
All you have to do to get this stuff working is add the following things to
your hivemodule.xml file...
1. Hibernate configuration (of course you'd use your own entity classes and
your own dialect and add other properties, etc.)...
<contribution configuration-id="tapernate.HibernateSettings">
<mapping class="com.myco.domain.entity.Account"/>
<property
name="hibernate.dialect"
value="org.hibernate.dialect.MySQLDialect"/>
</contribution>
2. If you want to use the "EntitySqueezer" (you'll have to comment it out
of Tapernate's hivemodule.xml file and re-build if you don't)...
<contribution configuration-id="tapernate.DataClasses">
<data-class>com.myco.domain.entity.AbstractEntity</data-class>
</contribution>
Here, AbstractEntity is a common superclass for all of your entities (most
people do that for Hibernate).
3. You can have your DAOs extends
com.carmanconsulting.tapernate.hibernate.HibernateService and they will
automatically have the Session injected into them.
4. Tapernate implements the "OpenSessionInView Pattern" automatically, so
you don't have to worry about that.
Now, this stuff is supplied as-is with no warranty or guarantees. Of
course, if you guys find something wrong with it, I'll fix it because I'm
using it in my own project. Enjoy!
-----Original Message-----
From: Anthony Fox [mailto:anthonyfox@gmail.com]
Sent: Wednesday, February 22, 2006 12:43 PM
To: Tapestry users
Subject: Re: hibernate detached objects as persistent page properties
I have considered a similar solution as I use Spring as well.
However, I was looking for a way to not have to _explicitly_ reattach
objects. Rather, I would like all persistent detached objects in the
session's context to reattach automatically. A filter or interceptor
with knowledge of what objects are hibernate detached objects and
reattached them automatically would be ideal. This would ease further
development as adding new persistent properties to pages wouldn't need
the additional step of adding these properties to the list of
properties to reattach at pageRender time. Have you considered or
seen a solution like the one I have described?
On 2/22/06, Shawn Church <sh...@boxity.com> wrote:
> I'm doing this in several applications. I normally use Spring also, but
> that is not really necessary. Tapestry isn't aware of the persistence
> implementation, but it does have to explicitly attach (and occasionally
> merge or evict) detached objects. Since I reference my DAO services in
> my Tapestry pages already, it seemed appropriate to create a
> "HibernateService" and "HibernateLegacyService" (I probably should have
> named them something more generic) with public methods supporting
> attach, merge, and evict. I have to support multiple, unrelated
> databases, hence the multiple session-management implementations. I
> only attach in pageBeginRender, although I occasionally have to merge or
> evict in my form listener.
>
> I believe Tapestry is best suited to working with detached objects (and
> this method is one which is recommended by the Hibernate team), rather
> than storing IDs and reloading. In my case especially where I have a
> lot of composite keys, passing IDs around would be a hack. Having the
> detached object available to Tapestry makes it very nice and seamless
> when I need access to collections or other objects within that object.
>
> I don't experience lazy initialization exceptions any more (unless I've
> done something really wrong), but NonUniqueObjectExceptions can creep in
> if for example I try to load an object which happens to already have
> been loaded within the same session within a collection of a parent
> object. This is again often the result of me doing something stupid,
> but there a few (rare in my case) legitimate instances where this is
> needed. In this case, I take care to first evict (or merge if
> appropriate) the duplicate object.
>
> Shawn
>
> Quoting Anthony Fox <an...@gmail.com>:
>
> > Hi,
> >
> > I have an application that has a lot of hibernate detached objects
> > (with lazy loaded collections) that are persistent page properties.
> > What are best practices for reattaching these detached objects while
> > maintaining a clean separation of layers? I have my implementation
> > specific persistence layer separated into DAOs, a service layer, and
> > the tapestry ui layer. I would like to keep tapestry independent of
> > the persistence layer. I am using the OpenSessionInView pattern to
> > open a new hibernate session for each web request. However, I can't
> > determine a clean way to reattach all the hibernate detached objects
> > at the beginning of each web request. I've noticed that some people
> > use pageBeginRender() to reattach objects, but I don't want to
> > expose
> > my tapestry code to the persistence implementation. An interceptor
> > or
> > filter or something that separated the ui layer from being aware of
> > the persistence layer would be ideal. How have others dealt with
> > this
> > issue?
> >
> > Thanks,
> > Anthony
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
You could do reattach objects with hibernateSession.lock( object, LockMode.NONE), but I suggest explicit reattaching with session.merge( object ).
Explicit merging is better IMO because easily allows "wizard"-like multi iteration editing of an object and then persisting all the changes if desired.
With automatic reattaching all the changes will be persisted as user proceeds and it makes harder to cancel all those changes....
Anthony Fox <an...@gmail.com> wrote: I have considered a similar solution as I use Spring as well.
However, I was looking for a way to not have to _explicitly_ reattach
objects. Rather, I would like all persistent detached objects in the
session's context to reattach automatically. A filter or interceptor
with knowledge of what objects are hibernate detached objects and
reattached them automatically would be ideal. This would ease further
development as adding new persistent properties to pages wouldn't need
the additional step of adding these properties to the list of
properties to reattach at pageRender time. Have you considered or
seen a solution like the one I have described?
On 2/22/06, Shawn Church wrote:
> I'm doing this in several applications. I normally use Spring also, but
> that is not really necessary. Tapestry isn't aware of the persistence
> implementation, but it does have to explicitly attach (and occasionally
> merge or evict) detached objects. Since I reference my DAO services in
> my Tapestry pages already, it seemed appropriate to create a
> "HibernateService" and "HibernateLegacyService" (I probably should have
> named them something more generic) with public methods supporting
> attach, merge, and evict. I have to support multiple, unrelated
> databases, hence the multiple session-management implementations. I
> only attach in pageBeginRender, although I occasionally have to merge or
> evict in my form listener.
>
> I believe Tapestry is best suited to working with detached objects (and
> this method is one which is recommended by the Hibernate team), rather
> than storing IDs and reloading. In my case especially where I have a
> lot of composite keys, passing IDs around would be a hack. Having the
> detached object available to Tapestry makes it very nice and seamless
> when I need access to collections or other objects within that object.
>
> I don't experience lazy initialization exceptions any more (unless I've
> done something really wrong), but NonUniqueObjectExceptions can creep in
> if for example I try to load an object which happens to already have
> been loaded within the same session within a collection of a parent
> object. This is again often the result of me doing something stupid,
> but there a few (rare in my case) legitimate instances where this is
> needed. In this case, I take care to first evict (or merge if
> appropriate) the duplicate object.
>
> Shawn
>
> Quoting Anthony Fox :
>
> > Hi,
> >
> > I have an application that has a lot of hibernate detached objects
> > (with lazy loaded collections) that are persistent page properties.
> > What are best practices for reattaching these detached objects while
> > maintaining a clean separation of layers? I have my implementation
> > specific persistence layer separated into DAOs, a service layer, and
> > the tapestry ui layer. I would like to keep tapestry independent of
> > the persistence layer. I am using the OpenSessionInView pattern to
> > open a new hibernate session for each web request. However, I can't
> > determine a clean way to reattach all the hibernate detached objects
> > at the beginning of each web request. I've noticed that some people
> > use pageBeginRender() to reattach objects, but I don't want to
> > expose
> > my tapestry code to the persistence implementation. An interceptor
> > or
> > filter or something that separated the ui layer from being aware of
> > the persistence layer would be ideal. How have others dealt with
> > this
> > issue?
> >
> > Thanks,
> > Anthony
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
Re: hibernate detached objects as persistent page properties
Posted by Anthony Fox <an...@gmail.com>.
I have considered a similar solution as I use Spring as well.
However, I was looking for a way to not have to _explicitly_ reattach
objects. Rather, I would like all persistent detached objects in the
session's context to reattach automatically. A filter or interceptor
with knowledge of what objects are hibernate detached objects and
reattached them automatically would be ideal. This would ease further
development as adding new persistent properties to pages wouldn't need
the additional step of adding these properties to the list of
properties to reattach at pageRender time. Have you considered or
seen a solution like the one I have described?
On 2/22/06, Shawn Church <sh...@boxity.com> wrote:
> I'm doing this in several applications. I normally use Spring also, but
> that is not really necessary. Tapestry isn't aware of the persistence
> implementation, but it does have to explicitly attach (and occasionally
> merge or evict) detached objects. Since I reference my DAO services in
> my Tapestry pages already, it seemed appropriate to create a
> "HibernateService" and "HibernateLegacyService" (I probably should have
> named them something more generic) with public methods supporting
> attach, merge, and evict. I have to support multiple, unrelated
> databases, hence the multiple session-management implementations. I
> only attach in pageBeginRender, although I occasionally have to merge or
> evict in my form listener.
>
> I believe Tapestry is best suited to working with detached objects (and
> this method is one which is recommended by the Hibernate team), rather
> than storing IDs and reloading. In my case especially where I have a
> lot of composite keys, passing IDs around would be a hack. Having the
> detached object available to Tapestry makes it very nice and seamless
> when I need access to collections or other objects within that object.
>
> I don't experience lazy initialization exceptions any more (unless I've
> done something really wrong), but NonUniqueObjectExceptions can creep in
> if for example I try to load an object which happens to already have
> been loaded within the same session within a collection of a parent
> object. This is again often the result of me doing something stupid,
> but there a few (rare in my case) legitimate instances where this is
> needed. In this case, I take care to first evict (or merge if
> appropriate) the duplicate object.
>
> Shawn
>
> Quoting Anthony Fox <an...@gmail.com>:
>
> > Hi,
> >
> > I have an application that has a lot of hibernate detached objects
> > (with lazy loaded collections) that are persistent page properties.
> > What are best practices for reattaching these detached objects while
> > maintaining a clean separation of layers? I have my implementation
> > specific persistence layer separated into DAOs, a service layer, and
> > the tapestry ui layer. I would like to keep tapestry independent of
> > the persistence layer. I am using the OpenSessionInView pattern to
> > open a new hibernate session for each web request. However, I can't
> > determine a clean way to reattach all the hibernate detached objects
> > at the beginning of each web request. I've noticed that some people
> > use pageBeginRender() to reattach objects, but I don't want to
> > expose
> > my tapestry code to the persistence implementation. An interceptor
> > or
> > filter or something that separated the ui layer from being aware of
> > the persistence layer would be ideal. How have others dealt with
> > this
> > issue?
> >
> > Thanks,
> > Anthony
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Shawn Church <sh...@boxity.com>.
I'm doing this in several applications. I normally use Spring also, but
that is not really necessary. Tapestry isn't aware of the persistence
implementation, but it does have to explicitly attach (and occasionally
merge or evict) detached objects. Since I reference my DAO services in
my Tapestry pages already, it seemed appropriate to create a
"HibernateService" and "HibernateLegacyService" (I probably should have
named them something more generic) with public methods supporting
attach, merge, and evict. I have to support multiple, unrelated
databases, hence the multiple session-management implementations. I
only attach in pageBeginRender, although I occasionally have to merge or
evict in my form listener.
I believe Tapestry is best suited to working with detached objects (and
this method is one which is recommended by the Hibernate team), rather
than storing IDs and reloading. In my case especially where I have a
lot of composite keys, passing IDs around would be a hack. Having the
detached object available to Tapestry makes it very nice and seamless
when I need access to collections or other objects within that object.
I don't experience lazy initialization exceptions any more (unless I've
done something really wrong), but NonUniqueObjectExceptions can creep in
if for example I try to load an object which happens to already have
been loaded within the same session within a collection of a parent
object. This is again often the result of me doing something stupid,
but there a few (rare in my case) legitimate instances where this is
needed. In this case, I take care to first evict (or merge if
appropriate) the duplicate object.
Shawn
Quoting Anthony Fox <an...@gmail.com>:
> Hi,
>
> I have an application that has a lot of hibernate detached objects
> (with lazy loaded collections) that are persistent page properties.
> What are best practices for reattaching these detached objects while
> maintaining a clean separation of layers? I have my implementation
> specific persistence layer separated into DAOs, a service layer, and
> the tapestry ui layer. I would like to keep tapestry independent of
> the persistence layer. I am using the OpenSessionInView pattern to
> open a new hibernate session for each web request. However, I can't
> determine a clean way to reattach all the hibernate detached objects
> at the beginning of each web request. I've noticed that some people
> use pageBeginRender() to reattach objects, but I don't want to
> expose
> my tapestry code to the persistence implementation. An interceptor
> or
> filter or something that separated the ui layer from being aware of
> the persistence layer would be ideal. How have others dealt with
> this
> issue?
>
> Thanks,
> Anthony
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: hibernate detached objects as persistent page properties
Posted by Anthony Fox <an...@gmail.com>.
Sure, I would like to take a look. Could you email it to me or make
it available?
On 2/22/06, James Carman <ja...@carmanconsulting.com> wrote:
> Well, I wrote something pretty cool the other day. It's a new storage
> strategy for Tapestry called "entity." Basically, if you try to store an
> object as a persistent page property that is a persistent entity, it doesn't
> store the actual object. It stores its identity information
> (entityName/id). If the object isn't persistent yet (an object you created
> via the "new" operator), it just stores it as-is in the session. If you
> would like the code, configuration information, just let me know.
>
>
>
> -----Original Message-----
> From: Anthony Fox [mailto:anthonyfox@gmail.com]
> Sent: Wednesday, February 22, 2006 8:12 AM
> To: Tapestry users
> Subject: hibernate detached objects as persistent page properties
>
> Hi,
>
> I have an application that has a lot of hibernate detached objects
> (with lazy loaded collections) that are persistent page properties.
> What are best practices for reattaching these detached objects while
> maintaining a clean separation of layers? I have my implementation
> specific persistence layer separated into DAOs, a service layer, and
> the tapestry ui layer. I would like to keep tapestry independent of
> the persistence layer. I am using the OpenSessionInView pattern to
> open a new hibernate session for each web request. However, I can't
> determine a clean way to reattach all the hibernate detached objects
> at the beginning of each web request. I've noticed that some people
> use pageBeginRender() to reattach objects, but I don't want to expose
> my tapestry code to the persistence implementation. An interceptor or
> filter or something that separated the ui layer from being aware of
> the persistence layer would be ideal. How have others dealt with this
> issue?
>
> Thanks,
> Anthony
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: hibernate detached objects as persistent page properties
Posted by James Carman <ja...@carmanconsulting.com>.
Well, I wrote something pretty cool the other day. It's a new storage
strategy for Tapestry called "entity." Basically, if you try to store an
object as a persistent page property that is a persistent entity, it doesn't
store the actual object. It stores its identity information
(entityName/id). If the object isn't persistent yet (an object you created
via the "new" operator), it just stores it as-is in the session. If you
would like the code, configuration information, just let me know.
-----Original Message-----
From: Anthony Fox [mailto:anthonyfox@gmail.com]
Sent: Wednesday, February 22, 2006 8:12 AM
To: Tapestry users
Subject: hibernate detached objects as persistent page properties
Hi,
I have an application that has a lot of hibernate detached objects
(with lazy loaded collections) that are persistent page properties.
What are best practices for reattaching these detached objects while
maintaining a clean separation of layers? I have my implementation
specific persistence layer separated into DAOs, a service layer, and
the tapestry ui layer. I would like to keep tapestry independent of
the persistence layer. I am using the OpenSessionInView pattern to
open a new hibernate session for each web request. However, I can't
determine a clean way to reattach all the hibernate detached objects
at the beginning of each web request. I've noticed that some people
use pageBeginRender() to reattach objects, but I don't want to expose
my tapestry code to the persistence implementation. An interceptor or
filter or something that separated the ui layer from being aware of
the persistence layer would be ideal. How have others dealt with this
issue?
Thanks,
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org