You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bill Holloway <bi...@gmail.com> on 2006/11/04 04:00:18 UTC
Tapestry-Hibernate
I've seen recently some criticism of Tapestry in terms of using
Hibernate. Problems with lazy loading. I know Tapernate is out
there, but the docs are pretty thin. I'm using the threadLocal
version of the much-documented HibernateUtil in a DAO layer. Going
well. What will Tapernate actually do for me? Does it really solve
the lazy-loading problem? Are there decent docs?
I would HATE to have to abandon tapestry to work around performance
problems falling out of non-lazy-loading.
Thanks,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Bill Holloway <bi...@gmail.com>.
I'm not sure I want to persist the session across requests. I think
session per request with detached objects is OK for us because
optimistic locking will almost certainly work. The opt. lock
versioning should be ok.
I looked at your examples and saw the hivemodule and hibernate.cfg
config files ok, but I didn't find any .java file. I was especially
interested in seeing your MessageDAOImpl source. I have a DAO layer
and the "threadlocal" version of HibernateUtil. I also don't know
anything about ACEGI security but it seems useful.
The main problem I'd like to be able to solve is the lazy-loading thing.
Thanks!
Bill
On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> Bill,
>
> The lazy loading problem can't really be solved in a generalized way.
> But, Tapernate does a lot of work for you. I wouldn't suggest using
> the property persistence strategies from Tapernate right now. I'm
> working on a new version that will hopefully be more robust. The main
> problem that I face is knowing exactly *how* to reattach the detached
> object to the session when a request comes in. There are a few
> different scenarios and the problem is knowing which one you're in!
> Also, if you use merge or update, then your object's state will be
> persisted at the end of the request (assuming that you leave
> transaction-per-request on). What if you don't really want the state
> persisted during that request (you're in the middle of a "wizard"
> perhaps)? I think the way to go is to use the
> session-per-conversation pattern, but I'm trying to come up with a
> good way to specify conversation boundaries. Also, should we support
> more than one conversation at a time (what if the user clicks to go to
> another part of your webapp from within your wizard)? If so, how do
> the potentially orphaned conversations get cleaned up? This is what
> causes me to loose sleep at night (yes, I need a life). :-)
>
>
>
> On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > I've seen recently some criticism of Tapestry in terms of using
> > Hibernate. Problems with lazy loading. I know Tapernate is out
> > there, but the docs are pretty thin. I'm using the threadLocal
> > version of the much-documented HibernateUtil in a DAO layer. Going
> > well. What will Tapernate actually do for me? Does it really solve
> > the lazy-loading problem? Are there decent docs?
> >
> > I would HATE to have to abandon tapestry to work around performance
> > problems falling out of non-lazy-loading.
> >
> > Thanks,
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
"Budgets are moral documents."
-- Ann Richards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Ed Ross <ed...@gmail.com>.
Glad to see tapernate is not an orphaned project. I don't quite understand
the "java-forge" thing. If Im on the tapernate page, I can go get to the
javaforge home page, but from the javaforge home page I can not find
tapernate (leading me to belive it was orphaned).
Is there a new version that will work with maven and tapestry 4.1.x ?
currently maven keeps pulling tapestr 4.0 jars down so I end up with
duplicate tapestyry jars in the classpath (4.1 & 4.0). ths of course causes
hivemind problems as well as other issues.
I do agree - some docs would make this much easier to use.
thanks for all your work
ed
On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> Bill,
>
> The lazy loading problem can't really be solved in a generalized way.
> But, Tapernate does a lot of work for you. I wouldn't suggest using
> the property persistence strategies from Tapernate right now. I'm
> working on a new version that will hopefully be more robust. The main
> problem that I face is knowing exactly *how* to reattach the detached
> object to the session when a request comes in. There are a few
> different scenarios and the problem is knowing which one you're in!
> Also, if you use merge or update, then your object's state will be
> persisted at the end of the request (assuming that you leave
> transaction-per-request on). What if you don't really want the state
> persisted during that request (you're in the middle of a "wizard"
> perhaps)? I think the way to go is to use the
> session-per-conversation pattern, but I'm trying to come up with a
> good way to specify conversation boundaries. Also, should we support
> more than one conversation at a time (what if the user clicks to go to
> another part of your webapp from within your wizard)? If so, how do
> the potentially orphaned conversations get cleaned up? This is what
> causes me to loose sleep at night (yes, I need a life). :-)
>
>
>
> On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > I've seen recently some criticism of Tapestry in terms of using
> > Hibernate. Problems with lazy loading. I know Tapernate is out
> > there, but the docs are pretty thin. I'm using the threadLocal
> > version of the much-documented HibernateUtil in a DAO layer. Going
> > well. What will Tapernate actually do for me? Does it really solve
> > the lazy-loading problem? Are there decent docs?
> >
> > I would HATE to have to abandon tapestry to work around performance
> > problems falling out of non-lazy-loading.
> >
> > Thanks,
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Ed Ross
edross15057@gmail.com
Re: Tapestry-Hibernate
Posted by Daniel Tabuenca <dt...@gmail.com>.
I use my own implementation of a session-per-conversation strategy.
What I do is I have a conversation manager that stores all
conversations for a user betwee requests. I persist the conversation
ID to the client using an @Persis("client") annotation. I attach the
conversation in the pageValidateListener() creating a new on if there
is no current conversationId. The conversation manager can be
configured with a conversation timeout so that it cleans up any stale
conversations. This allows several concurrent conversations which was
a requirement in my case. The one thing that one has to be careful is
locking access to the session to avoid any issues. Essentially what I
do is that concurrent requests in the same conversation are not
allowed to execute in parallel but rather one request is made to wait
until the other finishes so that there is no concurrent access to the
session. I had briefly looked at Seam before finding tapestry and
deciding I liked tapestry much better. However, I really liked the
conversation concept found in seam and I based some of my ideas on it
(although I haven't looked at Seam in a while now so I'm not sure how
it's implemented there). It would be really nice to make a
conversation mechanism allowing multiple concurrent conversations and
well defined start/end points natively in tapestry.
On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> Bill,
>
> The lazy loading problem can't really be solved in a generalized way.
> But, Tapernate does a lot of work for you. I wouldn't suggest using
> the property persistence strategies from Tapernate right now. I'm
> working on a new version that will hopefully be more robust. The main
> problem that I face is knowing exactly *how* to reattach the detached
> object to the session when a request comes in. There are a few
> different scenarios and the problem is knowing which one you're in!
> Also, if you use merge or update, then your object's state will be
> persisted at the end of the request (assuming that you leave
> transaction-per-request on). What if you don't really want the state
> persisted during that request (you're in the middle of a "wizard"
> perhaps)? I think the way to go is to use the
> session-per-conversation pattern, but I'm trying to come up with a
> good way to specify conversation boundaries. Also, should we support
> more than one conversation at a time (what if the user clicks to go to
> another part of your webapp from within your wizard)? If so, how do
> the potentially orphaned conversations get cleaned up? This is what
> causes me to loose sleep at night (yes, I need a life). :-)
>
>
>
> On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > I've seen recently some criticism of Tapestry in terms of using
> > Hibernate. Problems with lazy loading. I know Tapernate is out
> > there, but the docs are pretty thin. I'm using the threadLocal
> > version of the much-documented HibernateUtil in a DAO layer. Going
> > well. What will Tapernate actually do for me? Does it really solve
> > the lazy-loading problem? Are there decent docs?
> >
> > I would HATE to have to abandon tapestry to work around performance
> > problems falling out of non-lazy-loading.
> >
> > Thanks,
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Daniel Tabuenca <dt...@gmail.com>.
In order for lazy loading to work, the object needs to belong to a
session. What I was referring to, was that you can open a new session
and then call session.lock() on each object you wish to attach to the
new session. This method works great when what you are doing involves
a few well-defined objects. If what you are doing involves a large and
varying number of objects and object graphs then this method becomes
impractical. For this second situation keeping the session open seems
to work best (you are keeping these items in memory between requests
anyways, might as well keep their session open too).
On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
> I don't know about reconnecting the object in session-per-request.
> The session is not maintained between requests. I think that's
> session-per-conversation. There a version number column for the
> database entity that increments on the first entity select. If the
> version number doesn't match, a warning is raised...if I'm
> understanding hibernate properly.
>
> Cheers,
>
> Bill
>
> On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
> > So do you have some way of locking all objects to the new session on
> > the subsequent request? Is this automated in some way? My problem with
> > the session-per-request-with-detached-objects is that there needs to
> > be some way to easily identify and re-attach the set of objects that
> > will be used. I've found it easiest to just keep the session and
> > reconnect it to the database on the new request. The one problem with
> > this is if you conversation is long your session might grow too big
> > since things are not cleaned out of the session even if you
> > application does not hold any additional references. Maybe ideally it
> > would be to use some form of AOP to automatically lock objects to the
> > new session on demand. This seems like it'd be awfully useful, though
> > I'm not sure how feasible it is to implement.
> >
> > On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
> > > For the lazy loading, what about writing a custom servlet filter as
> > > recommended in the hibernate docs, one that handles the session for
> > > you? Let it sit out there in front of Tapestry and manage the
> > > sessions. I'm leaning toward
> > > session-per-request-with-detached-objects and letting optimistic
> > > locking handle the concurrency issues. I'm not so concerned about
> > > that issue.
> > >
> > > My real issue is with the lazy-loading. We'll have objects with some
> > > pretty hefty fields -- text and maybe blob types -- that I REALLY
> > > don't want to have loaded if I don't have to.
> > >
> > > Cheers,
> > > Bill
> > >
> > > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> > > > Bill,
> > > >
> > > > The lazy loading problem can't really be solved in a generalized way.
> > > > But, Tapernate does a lot of work for you. I wouldn't suggest using
> > > > the property persistence strategies from Tapernate right now. I'm
> > > > working on a new version that will hopefully be more robust. The main
> > > > problem that I face is knowing exactly *how* to reattach the detached
> > > > object to the session when a request comes in. There are a few
> > > > different scenarios and the problem is knowing which one you're in!
> > > > Also, if you use merge or update, then your object's state will be
> > > > persisted at the end of the request (assuming that you leave
> > > > transaction-per-request on). What if you don't really want the state
> > > > persisted during that request (you're in the middle of a "wizard"
> > > > perhaps)? I think the way to go is to use the
> > > > session-per-conversation pattern, but I'm trying to come up with a
> > > > good way to specify conversation boundaries. Also, should we support
> > > > more than one conversation at a time (what if the user clicks to go to
> > > > another part of your webapp from within your wizard)? If so, how do
> > > > the potentially orphaned conversations get cleaned up? This is what
> > > > causes me to loose sleep at night (yes, I need a life). :-)
> > > >
> > > >
> > > >
> > > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > > > > I've seen recently some criticism of Tapestry in terms of using
> > > > > Hibernate. Problems with lazy loading. I know Tapernate is out
> > > > > there, but the docs are pretty thin. I'm using the threadLocal
> > > > > version of the much-documented HibernateUtil in a DAO layer. Going
> > > > > well. What will Tapernate actually do for me? Does it really solve
> > > > > the lazy-loading problem? Are there decent docs?
> > > > >
> > > > > I would HATE to have to abandon tapestry to work around performance
> > > > > problems falling out of non-lazy-loading.
> > > > >
> > > > > Thanks,
> > > > > Bill
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > "Budgets are moral documents."
> > >
> > > -- Ann Richards
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> "Budgets are moral documents."
>
> -- Ann Richards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by andyhot <an...@di.uoa.gr>.
it's *.ajax if you've enabled the tacos ajax request encoder...
it's *ajaxdirect.svc if you have standard friendly urls
Daniel Tabuenca wrote:
> On mine it's :
>
> <filter-mapping>
> <filter-name>OpenSessionInViewFilter</filter-name>
> <url-pattern>*.ajax</url-pattern>
> </filter-mapping>
>
> I don't recall if .ajax is the default or if that's something I
> modified. In any case you can lookup what URL is actually being used
> in your request and make sure it matches that.
>
>
>
> On 11/5/06, gant@inextdot.com <ga...@inextdot.com> wrote:
>> great, thanks , this must be the reason. How do you define it?
>>
>> Like <url-pattern>*ajaxdirect.svc*</url-pattern> ?
>>
>>
>> ----- Original Message -----
>> From: "Daniel Tabuenca" <dt...@gmail.com>
>> To: "Tapestry users" <us...@tapestry.apache.org>
>> Sent: Sunday, November 05, 2006 16:35
>> Subject: Re: Tapestry-Hibernate
>>
>>
>> >A tacos asynchronous requests is still a standard request as far as
>> > the servlet is concenred. What is not working for you? I have used
>> > this same exact setup using a slightly modified version of Spring's
>> > OpenSessionInView filter and it works fine. Make sure you are using a
>> > filter-mapping that matches the urls used for tacos' ajax-direct
>> > service not just the normal Tapestry urls.
>> >
>> > On 11/4/06, gant@inextdot.com <ga...@inextdot.com> wrote:
>> >> Hi,
>> >>
>> >> I am using Hibernate+Spring+Tapestry and Spring's OpenSessionInView
>> >> filter.
>> >> It works fine with classical Http Requests. But it does not work with
>> >> asynchronous requests i.e. with tacos, perhaps now with tapestry
>> 4.1. If
>> >> you
>> >> have any ideas how to make it work i am interested.
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Bill Holloway" <bi...@gmail.com>
>> >> To: "Tapestry users" <us...@tapestry.apache.org>
>> >> Sent: Sunday, November 05, 2006 08:52
>> >> Subject: Re: Tapestry-Hibernate
>> >>
>> >>
>> >> >I don't know about reconnecting the object in session-per-request.
>> >> > The session is not maintained between requests. I think that's
>> >> > session-per-conversation. There a version number column for the
>> >> > database entity that increments on the first entity select. If the
>> >> > version number doesn't match, a warning is raised...if I'm
>> >> > understanding hibernate properly.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Bill
>> >> >
>> >> > On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
>> >> >> So do you have some way of locking all objects to the new
>> session on
>> >> >> the subsequent request? Is this automated in some way? My
>> problem with
>> >> >> the session-per-request-with-detached-objects is that there
>> needs to
>> >> >> be some way to easily identify and re-attach the set of objects
>> that
>> >> >> will be used. I've found it easiest to just keep the session and
>> >> >> reconnect it to the database on the new request. The one
>> problem with
>> >> >> this is if you conversation is long your session might grow too
>> big
>> >> >> since things are not cleaned out of the session even if you
>> >> >> application does not hold any additional references. Maybe
>> ideally it
>> >> >> would be to use some form of AOP to automatically lock objects
>> to the
>> >> >> new session on demand. This seems like it'd be awfully useful,
>> though
>> >> >> I'm not sure how feasible it is to implement.
>> >> >>
>> >> >> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
>> >> >> > For the lazy loading, what about writing a custom servlet
>> filter as
>> >> >> > recommended in the hibernate docs, one that handles the
>> session for
>> >> >> > you? Let it sit out there in front of Tapestry and manage the
>> >> >> > sessions. I'm leaning toward
>> >> >> > session-per-request-with-detached-objects and letting optimistic
>> >> >> > locking handle the concurrency issues. I'm not so concerned
>> about
>> >> >> > that issue.
>> >> >> >
>> >> >> > My real issue is with the lazy-loading. We'll have objects with
>> >> >> > some
>> >> >> > pretty hefty fields -- text and maybe blob types -- that I
>> REALLY
>> >> >> > don't want to have loaded if I don't have to.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Bill
>> >> >> >
>> >> >> > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
>> >> >> > > Bill,
>> >> >> > >
>> >> >> > > The lazy loading problem can't really be solved in a
>> generalized
>> >> >> > > way.
>> >> >> > > But, Tapernate does a lot of work for you. I wouldn't suggest
>> >> >> > > using
>> >> >> > > the property persistence strategies from Tapernate right
>> now. I'm
>> >> >> > > working on a new version that will hopefully be more
>> robust. The
>> >> >> > > main
>> >> >> > > problem that I face is knowing exactly *how* to reattach the
>> >> >> > > detached
>> >> >> > > object to the session when a request comes in. There are a
>> few
>> >> >> > > different scenarios and the problem is knowing which one
>> you're
>> >> >> > > in!
>> >> >> > > Also, if you use merge or update, then your object's state
>> will be
>> >> >> > > persisted at the end of the request (assuming that you leave
>> >> >> > > transaction-per-request on). What if you don't really want
>> the
>> >> >> > > state
>> >> >> > > persisted during that request (you're in the middle of a
>> "wizard"
>> >> >> > > perhaps)? I think the way to go is to use the
>> >> >> > > session-per-conversation pattern, but I'm trying to come up
>> with a
>> >> >> > > good way to specify conversation boundaries. Also, should we
>> >> >> > > support
>> >> >> > > more than one conversation at a time (what if the user
>> clicks to
>> >> >> > > go
>> >> >> > > to
>> >> >> > > another part of your webapp from within your wizard)? If
>> so, how
>> >> >> > > do
>> >> >> > > the potentially orphaned conversations get cleaned up?
>> This is
>> >> >> > > what
>> >> >> > > causes me to loose sleep at night (yes, I need a life). :-)
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >> > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
>> >> >> > > > I've seen recently some criticism of Tapestry in terms of
>> using
>> >> >> > > > Hibernate. Problems with lazy loading. I know Tapernate
>> is out
>> >> >> > > > there, but the docs are pretty thin. I'm using the
>> threadLocal
>> >> >> > > > version of the much-documented HibernateUtil in a DAO layer.
>> >> >> > > > Going
>> >> >> > > > well. What will Tapernate actually do for me? Does it
>> really
>> >> >> > > > solve
>> >> >> > > > the lazy-loading problem? Are there decent docs?
>> >> >> > > >
>> >> >> > > > I would HATE to have to abandon tapestry to work around
>> >> >> > > > performance
>> >> >> > > > problems falling out of non-lazy-loading.
>> >> >> > > >
>> >> >> > > > Thanks,
>> >> >> > > > Bill
>> >> >> > > >
>> >> >> > > >
>> ---------------------------------------------------------------------
>> >> >> > > > To unsubscribe, e-mail:
>> users-unsubscribe@tapestry.apache.org
>> >> >> > > > For additional commands, e-mail:
>> users-help@tapestry.apache.org
>> >> >> > > >
>> >> >> > > >
>> >> >> > >
>> >> >> > >
>> ---------------------------------------------------------------------
>> >> >> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> > > For additional commands, e-mail:
>> users-help@tapestry.apache.org
>> >> >> > >
>> >> >> > >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > "Budgets are moral documents."
>> >> >> >
>> >> >> > -- Ann Richards
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > "Budgets are moral documents."
>> >> >
>> >> > -- Ann Richards
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Daniel Tabuenca <dt...@gmail.com>.
On mine it's :
<filter-mapping>
<filter-name>OpenSessionInViewFilter</filter-name>
<url-pattern>*.ajax</url-pattern>
</filter-mapping>
I don't recall if .ajax is the default or if that's something I
modified. In any case you can lookup what URL is actually being used
in your request and make sure it matches that.
On 11/5/06, gant@inextdot.com <ga...@inextdot.com> wrote:
> great, thanks , this must be the reason. How do you define it?
>
> Like <url-pattern>*ajaxdirect.svc*</url-pattern> ?
>
>
> ----- Original Message -----
> From: "Daniel Tabuenca" <dt...@gmail.com>
> To: "Tapestry users" <us...@tapestry.apache.org>
> Sent: Sunday, November 05, 2006 16:35
> Subject: Re: Tapestry-Hibernate
>
>
> >A tacos asynchronous requests is still a standard request as far as
> > the servlet is concenred. What is not working for you? I have used
> > this same exact setup using a slightly modified version of Spring's
> > OpenSessionInView filter and it works fine. Make sure you are using a
> > filter-mapping that matches the urls used for tacos' ajax-direct
> > service not just the normal Tapestry urls.
> >
> > On 11/4/06, gant@inextdot.com <ga...@inextdot.com> wrote:
> >> Hi,
> >>
> >> I am using Hibernate+Spring+Tapestry and Spring's OpenSessionInView
> >> filter.
> >> It works fine with classical Http Requests. But it does not work with
> >> asynchronous requests i.e. with tacos, perhaps now with tapestry 4.1. If
> >> you
> >> have any ideas how to make it work i am interested.
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: "Bill Holloway" <bi...@gmail.com>
> >> To: "Tapestry users" <us...@tapestry.apache.org>
> >> Sent: Sunday, November 05, 2006 08:52
> >> Subject: Re: Tapestry-Hibernate
> >>
> >>
> >> >I don't know about reconnecting the object in session-per-request.
> >> > The session is not maintained between requests. I think that's
> >> > session-per-conversation. There a version number column for the
> >> > database entity that increments on the first entity select. If the
> >> > version number doesn't match, a warning is raised...if I'm
> >> > understanding hibernate properly.
> >> >
> >> > Cheers,
> >> >
> >> > Bill
> >> >
> >> > On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
> >> >> So do you have some way of locking all objects to the new session on
> >> >> the subsequent request? Is this automated in some way? My problem with
> >> >> the session-per-request-with-detached-objects is that there needs to
> >> >> be some way to easily identify and re-attach the set of objects that
> >> >> will be used. I've found it easiest to just keep the session and
> >> >> reconnect it to the database on the new request. The one problem with
> >> >> this is if you conversation is long your session might grow too big
> >> >> since things are not cleaned out of the session even if you
> >> >> application does not hold any additional references. Maybe ideally it
> >> >> would be to use some form of AOP to automatically lock objects to the
> >> >> new session on demand. This seems like it'd be awfully useful, though
> >> >> I'm not sure how feasible it is to implement.
> >> >>
> >> >> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
> >> >> > For the lazy loading, what about writing a custom servlet filter as
> >> >> > recommended in the hibernate docs, one that handles the session for
> >> >> > you? Let it sit out there in front of Tapestry and manage the
> >> >> > sessions. I'm leaning toward
> >> >> > session-per-request-with-detached-objects and letting optimistic
> >> >> > locking handle the concurrency issues. I'm not so concerned about
> >> >> > that issue.
> >> >> >
> >> >> > My real issue is with the lazy-loading. We'll have objects with
> >> >> > some
> >> >> > pretty hefty fields -- text and maybe blob types -- that I REALLY
> >> >> > don't want to have loaded if I don't have to.
> >> >> >
> >> >> > Cheers,
> >> >> > Bill
> >> >> >
> >> >> > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> >> >> > > Bill,
> >> >> > >
> >> >> > > The lazy loading problem can't really be solved in a generalized
> >> >> > > way.
> >> >> > > But, Tapernate does a lot of work for you. I wouldn't suggest
> >> >> > > using
> >> >> > > the property persistence strategies from Tapernate right now. I'm
> >> >> > > working on a new version that will hopefully be more robust. The
> >> >> > > main
> >> >> > > problem that I face is knowing exactly *how* to reattach the
> >> >> > > detached
> >> >> > > object to the session when a request comes in. There are a few
> >> >> > > different scenarios and the problem is knowing which one you're
> >> >> > > in!
> >> >> > > Also, if you use merge or update, then your object's state will be
> >> >> > > persisted at the end of the request (assuming that you leave
> >> >> > > transaction-per-request on). What if you don't really want the
> >> >> > > state
> >> >> > > persisted during that request (you're in the middle of a "wizard"
> >> >> > > perhaps)? I think the way to go is to use the
> >> >> > > session-per-conversation pattern, but I'm trying to come up with a
> >> >> > > good way to specify conversation boundaries. Also, should we
> >> >> > > support
> >> >> > > more than one conversation at a time (what if the user clicks to
> >> >> > > go
> >> >> > > to
> >> >> > > another part of your webapp from within your wizard)? If so, how
> >> >> > > do
> >> >> > > the potentially orphaned conversations get cleaned up? This is
> >> >> > > what
> >> >> > > causes me to loose sleep at night (yes, I need a life). :-)
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> >> >> > > > I've seen recently some criticism of Tapestry in terms of using
> >> >> > > > Hibernate. Problems with lazy loading. I know Tapernate is out
> >> >> > > > there, but the docs are pretty thin. I'm using the threadLocal
> >> >> > > > version of the much-documented HibernateUtil in a DAO layer.
> >> >> > > > Going
> >> >> > > > well. What will Tapernate actually do for me? Does it really
> >> >> > > > solve
> >> >> > > > the lazy-loading problem? Are there decent docs?
> >> >> > > >
> >> >> > > > I would HATE to have to abandon tapestry to work around
> >> >> > > > performance
> >> >> > > > problems falling out of non-lazy-loading.
> >> >> > > >
> >> >> > > > Thanks,
> >> >> > > > Bill
> >> >> > > >
> >> >> > > > ---------------------------------------------------------------------
> >> >> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > > ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> > > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > "Budgets are moral documents."
> >> >> >
> >> >> > -- Ann Richards
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > "Budgets are moral documents."
> >> >
> >> > -- Ann Richards
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by ga...@inextdot.com.
great, thanks , this must be the reason. How do you define it?
Like <url-pattern>*ajaxdirect.svc*</url-pattern> ?
----- Original Message -----
From: "Daniel Tabuenca" <dt...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Sunday, November 05, 2006 16:35
Subject: Re: Tapestry-Hibernate
>A tacos asynchronous requests is still a standard request as far as
> the servlet is concenred. What is not working for you? I have used
> this same exact setup using a slightly modified version of Spring's
> OpenSessionInView filter and it works fine. Make sure you are using a
> filter-mapping that matches the urls used for tacos' ajax-direct
> service not just the normal Tapestry urls.
>
> On 11/4/06, gant@inextdot.com <ga...@inextdot.com> wrote:
>> Hi,
>>
>> I am using Hibernate+Spring+Tapestry and Spring's OpenSessionInView
>> filter.
>> It works fine with classical Http Requests. But it does not work with
>> asynchronous requests i.e. with tacos, perhaps now with tapestry 4.1. If
>> you
>> have any ideas how to make it work i am interested.
>>
>>
>>
>> ----- Original Message -----
>> From: "Bill Holloway" <bi...@gmail.com>
>> To: "Tapestry users" <us...@tapestry.apache.org>
>> Sent: Sunday, November 05, 2006 08:52
>> Subject: Re: Tapestry-Hibernate
>>
>>
>> >I don't know about reconnecting the object in session-per-request.
>> > The session is not maintained between requests. I think that's
>> > session-per-conversation. There a version number column for the
>> > database entity that increments on the first entity select. If the
>> > version number doesn't match, a warning is raised...if I'm
>> > understanding hibernate properly.
>> >
>> > Cheers,
>> >
>> > Bill
>> >
>> > On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
>> >> So do you have some way of locking all objects to the new session on
>> >> the subsequent request? Is this automated in some way? My problem with
>> >> the session-per-request-with-detached-objects is that there needs to
>> >> be some way to easily identify and re-attach the set of objects that
>> >> will be used. I've found it easiest to just keep the session and
>> >> reconnect it to the database on the new request. The one problem with
>> >> this is if you conversation is long your session might grow too big
>> >> since things are not cleaned out of the session even if you
>> >> application does not hold any additional references. Maybe ideally it
>> >> would be to use some form of AOP to automatically lock objects to the
>> >> new session on demand. This seems like it'd be awfully useful, though
>> >> I'm not sure how feasible it is to implement.
>> >>
>> >> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
>> >> > For the lazy loading, what about writing a custom servlet filter as
>> >> > recommended in the hibernate docs, one that handles the session for
>> >> > you? Let it sit out there in front of Tapestry and manage the
>> >> > sessions. I'm leaning toward
>> >> > session-per-request-with-detached-objects and letting optimistic
>> >> > locking handle the concurrency issues. I'm not so concerned about
>> >> > that issue.
>> >> >
>> >> > My real issue is with the lazy-loading. We'll have objects with
>> >> > some
>> >> > pretty hefty fields -- text and maybe blob types -- that I REALLY
>> >> > don't want to have loaded if I don't have to.
>> >> >
>> >> > Cheers,
>> >> > Bill
>> >> >
>> >> > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
>> >> > > Bill,
>> >> > >
>> >> > > The lazy loading problem can't really be solved in a generalized
>> >> > > way.
>> >> > > But, Tapernate does a lot of work for you. I wouldn't suggest
>> >> > > using
>> >> > > the property persistence strategies from Tapernate right now. I'm
>> >> > > working on a new version that will hopefully be more robust. The
>> >> > > main
>> >> > > problem that I face is knowing exactly *how* to reattach the
>> >> > > detached
>> >> > > object to the session when a request comes in. There are a few
>> >> > > different scenarios and the problem is knowing which one you're
>> >> > > in!
>> >> > > Also, if you use merge or update, then your object's state will be
>> >> > > persisted at the end of the request (assuming that you leave
>> >> > > transaction-per-request on). What if you don't really want the
>> >> > > state
>> >> > > persisted during that request (you're in the middle of a "wizard"
>> >> > > perhaps)? I think the way to go is to use the
>> >> > > session-per-conversation pattern, but I'm trying to come up with a
>> >> > > good way to specify conversation boundaries. Also, should we
>> >> > > support
>> >> > > more than one conversation at a time (what if the user clicks to
>> >> > > go
>> >> > > to
>> >> > > another part of your webapp from within your wizard)? If so, how
>> >> > > do
>> >> > > the potentially orphaned conversations get cleaned up? This is
>> >> > > what
>> >> > > causes me to loose sleep at night (yes, I need a life). :-)
>> >> > >
>> >> > >
>> >> > >
>> >> > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
>> >> > > > I've seen recently some criticism of Tapestry in terms of using
>> >> > > > Hibernate. Problems with lazy loading. I know Tapernate is out
>> >> > > > there, but the docs are pretty thin. I'm using the threadLocal
>> >> > > > version of the much-documented HibernateUtil in a DAO layer.
>> >> > > > Going
>> >> > > > well. What will Tapernate actually do for me? Does it really
>> >> > > > solve
>> >> > > > the lazy-loading problem? Are there decent docs?
>> >> > > >
>> >> > > > I would HATE to have to abandon tapestry to work around
>> >> > > > performance
>> >> > > > problems falling out of non-lazy-loading.
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Bill
>> >> > > >
>> >> > > > ---------------------------------------------------------------------
>> >> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> > > >
>> >> > > >
>> >> > >
>> >> > > ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > "Budgets are moral documents."
>> >> >
>> >> > -- Ann Richards
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > "Budgets are moral documents."
>> >
>> > -- Ann Richards
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Daniel Tabuenca <dt...@gmail.com>.
A tacos asynchronous requests is still a standard request as far as
the servlet is concenred. What is not working for you? I have used
this same exact setup using a slightly modified version of Spring's
OpenSessionInView filter and it works fine. Make sure you are using a
filter-mapping that matches the urls used for tacos' ajax-direct
service not just the normal Tapestry urls.
On 11/4/06, gant@inextdot.com <ga...@inextdot.com> wrote:
> Hi,
>
> I am using Hibernate+Spring+Tapestry and Spring's OpenSessionInView filter.
> It works fine with classical Http Requests. But it does not work with
> asynchronous requests i.e. with tacos, perhaps now with tapestry 4.1. If you
> have any ideas how to make it work i am interested.
>
>
>
> ----- Original Message -----
> From: "Bill Holloway" <bi...@gmail.com>
> To: "Tapestry users" <us...@tapestry.apache.org>
> Sent: Sunday, November 05, 2006 08:52
> Subject: Re: Tapestry-Hibernate
>
>
> >I don't know about reconnecting the object in session-per-request.
> > The session is not maintained between requests. I think that's
> > session-per-conversation. There a version number column for the
> > database entity that increments on the first entity select. If the
> > version number doesn't match, a warning is raised...if I'm
> > understanding hibernate properly.
> >
> > Cheers,
> >
> > Bill
> >
> > On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
> >> So do you have some way of locking all objects to the new session on
> >> the subsequent request? Is this automated in some way? My problem with
> >> the session-per-request-with-detached-objects is that there needs to
> >> be some way to easily identify and re-attach the set of objects that
> >> will be used. I've found it easiest to just keep the session and
> >> reconnect it to the database on the new request. The one problem with
> >> this is if you conversation is long your session might grow too big
> >> since things are not cleaned out of the session even if you
> >> application does not hold any additional references. Maybe ideally it
> >> would be to use some form of AOP to automatically lock objects to the
> >> new session on demand. This seems like it'd be awfully useful, though
> >> I'm not sure how feasible it is to implement.
> >>
> >> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
> >> > For the lazy loading, what about writing a custom servlet filter as
> >> > recommended in the hibernate docs, one that handles the session for
> >> > you? Let it sit out there in front of Tapestry and manage the
> >> > sessions. I'm leaning toward
> >> > session-per-request-with-detached-objects and letting optimistic
> >> > locking handle the concurrency issues. I'm not so concerned about
> >> > that issue.
> >> >
> >> > My real issue is with the lazy-loading. We'll have objects with some
> >> > pretty hefty fields -- text and maybe blob types -- that I REALLY
> >> > don't want to have loaded if I don't have to.
> >> >
> >> > Cheers,
> >> > Bill
> >> >
> >> > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> >> > > Bill,
> >> > >
> >> > > The lazy loading problem can't really be solved in a generalized way.
> >> > > But, Tapernate does a lot of work for you. I wouldn't suggest using
> >> > > the property persistence strategies from Tapernate right now. I'm
> >> > > working on a new version that will hopefully be more robust. The
> >> > > main
> >> > > problem that I face is knowing exactly *how* to reattach the detached
> >> > > object to the session when a request comes in. There are a few
> >> > > different scenarios and the problem is knowing which one you're in!
> >> > > Also, if you use merge or update, then your object's state will be
> >> > > persisted at the end of the request (assuming that you leave
> >> > > transaction-per-request on). What if you don't really want the state
> >> > > persisted during that request (you're in the middle of a "wizard"
> >> > > perhaps)? I think the way to go is to use the
> >> > > session-per-conversation pattern, but I'm trying to come up with a
> >> > > good way to specify conversation boundaries. Also, should we support
> >> > > more than one conversation at a time (what if the user clicks to go
> >> > > to
> >> > > another part of your webapp from within your wizard)? If so, how do
> >> > > the potentially orphaned conversations get cleaned up? This is
> >> > > what
> >> > > causes me to loose sleep at night (yes, I need a life). :-)
> >> > >
> >> > >
> >> > >
> >> > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> >> > > > I've seen recently some criticism of Tapestry in terms of using
> >> > > > Hibernate. Problems with lazy loading. I know Tapernate is out
> >> > > > there, but the docs are pretty thin. I'm using the threadLocal
> >> > > > version of the much-documented HibernateUtil in a DAO layer. Going
> >> > > > well. What will Tapernate actually do for me? Does it really
> >> > > > solve
> >> > > > the lazy-loading problem? Are there decent docs?
> >> > > >
> >> > > > I would HATE to have to abandon tapestry to work around performance
> >> > > > problems falling out of non-lazy-loading.
> >> > > >
> >> > > > Thanks,
> >> > > > Bill
> >> > > >
> >> > > > ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > > For additional commands, e-mail: users-help@tapestry.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > "Budgets are moral documents."
> >> >
> >> > -- Ann Richards
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > "Budgets are moral documents."
> >
> > -- Ann Richards
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by ga...@inextdot.com.
Hi,
I am using Hibernate+Spring+Tapestry and Spring's OpenSessionInView filter.
It works fine with classical Http Requests. But it does not work with
asynchronous requests i.e. with tacos, perhaps now with tapestry 4.1. If you
have any ideas how to make it work i am interested.
----- Original Message -----
From: "Bill Holloway" <bi...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Sunday, November 05, 2006 08:52
Subject: Re: Tapestry-Hibernate
>I don't know about reconnecting the object in session-per-request.
> The session is not maintained between requests. I think that's
> session-per-conversation. There a version number column for the
> database entity that increments on the first entity select. If the
> version number doesn't match, a warning is raised...if I'm
> understanding hibernate properly.
>
> Cheers,
>
> Bill
>
> On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
>> So do you have some way of locking all objects to the new session on
>> the subsequent request? Is this automated in some way? My problem with
>> the session-per-request-with-detached-objects is that there needs to
>> be some way to easily identify and re-attach the set of objects that
>> will be used. I've found it easiest to just keep the session and
>> reconnect it to the database on the new request. The one problem with
>> this is if you conversation is long your session might grow too big
>> since things are not cleaned out of the session even if you
>> application does not hold any additional references. Maybe ideally it
>> would be to use some form of AOP to automatically lock objects to the
>> new session on demand. This seems like it'd be awfully useful, though
>> I'm not sure how feasible it is to implement.
>>
>> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
>> > For the lazy loading, what about writing a custom servlet filter as
>> > recommended in the hibernate docs, one that handles the session for
>> > you? Let it sit out there in front of Tapestry and manage the
>> > sessions. I'm leaning toward
>> > session-per-request-with-detached-objects and letting optimistic
>> > locking handle the concurrency issues. I'm not so concerned about
>> > that issue.
>> >
>> > My real issue is with the lazy-loading. We'll have objects with some
>> > pretty hefty fields -- text and maybe blob types -- that I REALLY
>> > don't want to have loaded if I don't have to.
>> >
>> > Cheers,
>> > Bill
>> >
>> > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
>> > > Bill,
>> > >
>> > > The lazy loading problem can't really be solved in a generalized way.
>> > > But, Tapernate does a lot of work for you. I wouldn't suggest using
>> > > the property persistence strategies from Tapernate right now. I'm
>> > > working on a new version that will hopefully be more robust. The
>> > > main
>> > > problem that I face is knowing exactly *how* to reattach the detached
>> > > object to the session when a request comes in. There are a few
>> > > different scenarios and the problem is knowing which one you're in!
>> > > Also, if you use merge or update, then your object's state will be
>> > > persisted at the end of the request (assuming that you leave
>> > > transaction-per-request on). What if you don't really want the state
>> > > persisted during that request (you're in the middle of a "wizard"
>> > > perhaps)? I think the way to go is to use the
>> > > session-per-conversation pattern, but I'm trying to come up with a
>> > > good way to specify conversation boundaries. Also, should we support
>> > > more than one conversation at a time (what if the user clicks to go
>> > > to
>> > > another part of your webapp from within your wizard)? If so, how do
>> > > the potentially orphaned conversations get cleaned up? This is
>> > > what
>> > > causes me to loose sleep at night (yes, I need a life). :-)
>> > >
>> > >
>> > >
>> > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
>> > > > I've seen recently some criticism of Tapestry in terms of using
>> > > > Hibernate. Problems with lazy loading. I know Tapernate is out
>> > > > there, but the docs are pretty thin. I'm using the threadLocal
>> > > > version of the much-documented HibernateUtil in a DAO layer. Going
>> > > > well. What will Tapernate actually do for me? Does it really
>> > > > solve
>> > > > the lazy-loading problem? Are there decent docs?
>> > > >
>> > > > I would HATE to have to abandon tapestry to work around performance
>> > > > problems falling out of non-lazy-loading.
>> > > >
>> > > > Thanks,
>> > > > Bill
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > "Budgets are moral documents."
>> >
>> > -- Ann Richards
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> "Budgets are moral documents."
>
> -- Ann Richards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Bill Holloway <bi...@gmail.com>.
I don't know about reconnecting the object in session-per-request.
The session is not maintained between requests. I think that's
session-per-conversation. There a version number column for the
database entity that increments on the first entity select. If the
version number doesn't match, a warning is raised...if I'm
understanding hibernate properly.
Cheers,
Bill
On 11/4/06, Daniel Tabuenca <dt...@gmail.com> wrote:
> So do you have some way of locking all objects to the new session on
> the subsequent request? Is this automated in some way? My problem with
> the session-per-request-with-detached-objects is that there needs to
> be some way to easily identify and re-attach the set of objects that
> will be used. I've found it easiest to just keep the session and
> reconnect it to the database on the new request. The one problem with
> this is if you conversation is long your session might grow too big
> since things are not cleaned out of the session even if you
> application does not hold any additional references. Maybe ideally it
> would be to use some form of AOP to automatically lock objects to the
> new session on demand. This seems like it'd be awfully useful, though
> I'm not sure how feasible it is to implement.
>
> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
> > For the lazy loading, what about writing a custom servlet filter as
> > recommended in the hibernate docs, one that handles the session for
> > you? Let it sit out there in front of Tapestry and manage the
> > sessions. I'm leaning toward
> > session-per-request-with-detached-objects and letting optimistic
> > locking handle the concurrency issues. I'm not so concerned about
> > that issue.
> >
> > My real issue is with the lazy-loading. We'll have objects with some
> > pretty hefty fields -- text and maybe blob types -- that I REALLY
> > don't want to have loaded if I don't have to.
> >
> > Cheers,
> > Bill
> >
> > On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> > > Bill,
> > >
> > > The lazy loading problem can't really be solved in a generalized way.
> > > But, Tapernate does a lot of work for you. I wouldn't suggest using
> > > the property persistence strategies from Tapernate right now. I'm
> > > working on a new version that will hopefully be more robust. The main
> > > problem that I face is knowing exactly *how* to reattach the detached
> > > object to the session when a request comes in. There are a few
> > > different scenarios and the problem is knowing which one you're in!
> > > Also, if you use merge or update, then your object's state will be
> > > persisted at the end of the request (assuming that you leave
> > > transaction-per-request on). What if you don't really want the state
> > > persisted during that request (you're in the middle of a "wizard"
> > > perhaps)? I think the way to go is to use the
> > > session-per-conversation pattern, but I'm trying to come up with a
> > > good way to specify conversation boundaries. Also, should we support
> > > more than one conversation at a time (what if the user clicks to go to
> > > another part of your webapp from within your wizard)? If so, how do
> > > the potentially orphaned conversations get cleaned up? This is what
> > > causes me to loose sleep at night (yes, I need a life). :-)
> > >
> > >
> > >
> > > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > > > I've seen recently some criticism of Tapestry in terms of using
> > > > Hibernate. Problems with lazy loading. I know Tapernate is out
> > > > there, but the docs are pretty thin. I'm using the threadLocal
> > > > version of the much-documented HibernateUtil in a DAO layer. Going
> > > > well. What will Tapernate actually do for me? Does it really solve
> > > > the lazy-loading problem? Are there decent docs?
> > > >
> > > > I would HATE to have to abandon tapestry to work around performance
> > > > problems falling out of non-lazy-loading.
> > > >
> > > > Thanks,
> > > > Bill
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > "Budgets are moral documents."
> >
> > -- Ann Richards
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
"Budgets are moral documents."
-- Ann Richards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Steve Shucker <ss...@vmsinfo.com>.
I've used AspectJ to do this. It works, but it's not the most efficient
solution out there. We have all our entities implement an interface
"Persistent", so the pointcut looks like:
pointcut persistentUse(Persistent persistent):
call(java.util.Set+ Persistent+.get*()) && target(persistent) //
call to persistent setter
&& within(com.vms..*) // in our code
&& !cflow(call(Persistent+.new(..)) && within(com.vms..*)); //
ignore our constructors
Object around(Persistent persistent) :persistentUse(persistent){
persistent.associateWithCurrentSession();
Set result = (Set)proceed(persistent);
for (Iterator iter = result.iterator(); iter.hasNext();) {
Persistent collectionElement = (Persistent) iter.next();
if (collectionElement != null) {
collectionElement.associateWithCurrentSession();
}
}
return result;
}
associateWithCurrentSession() is a method on the Persistent interface
(multiple inheritance with AspectJ!) that detects if we have a current
session. If we have one, it does a lock().
Good:
- We don't have to think about this 95% of the time and it just works
Bad:
- It's inefficient to call this on every collection getter
- Every so often, we get bit on the rare case where we call a setter
method and forget to re-enlist. We could easily add setters to the
pointcut, but that gets even more inefficient.
- Not tested on hibernate3 (works on hibernate2)
I'm really looking for a better way to do this and watching to see what
James comes up with in the next version of tapernate.
-Steve
Daniel Tabuenca wrote:
> So do you have some way of locking all objects to the new session on
> the subsequent request? Is this automated in some way? My problem with
> the session-per-request-with-detached-objects is that there needs to
> be some way to easily identify and re-attach the set of objects that
> will be used. I've found it easiest to just keep the session and
> reconnect it to the database on the new request. The one problem with
> this is if you conversation is long your session might grow too big
> since things are not cleaned out of the session even if you
> application does not hold any additional references. Maybe ideally it
> would be to use some form of AOP to automatically lock objects to the
> new session on demand. This seems like it'd be awfully useful, though
> I'm not sure how feasible it is to implement.
>
> On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
>> For the lazy loading, what about writing a custom servlet filter as
>> recommended in the hibernate docs, one that handles the session for
>> you? Let it sit out there in front of Tapestry and manage the
>> sessions. I'm leaning toward
>> session-per-request-with-detached-objects and letting optimistic
>> locking handle the concurrency issues. I'm not so concerned about
>> that issue.
>>
>> My real issue is with the lazy-loading. We'll have objects with some
>> pretty hefty fields -- text and maybe blob types -- that I REALLY
>> don't want to have loaded if I don't have to.
>>
>> Cheers,
>> Bill
>>
>> On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
>> > Bill,
>> >
>> > The lazy loading problem can't really be solved in a generalized way.
>> > But, Tapernate does a lot of work for you. I wouldn't suggest using
>> > the property persistence strategies from Tapernate right now. I'm
>> > working on a new version that will hopefully be more robust. The main
>> > problem that I face is knowing exactly *how* to reattach the detached
>> > object to the session when a request comes in. There are a few
>> > different scenarios and the problem is knowing which one you're in!
>> > Also, if you use merge or update, then your object's state will be
>> > persisted at the end of the request (assuming that you leave
>> > transaction-per-request on). What if you don't really want the state
>> > persisted during that request (you're in the middle of a "wizard"
>> > perhaps)? I think the way to go is to use the
>> > session-per-conversation pattern, but I'm trying to come up with a
>> > good way to specify conversation boundaries. Also, should we support
>> > more than one conversation at a time (what if the user clicks to go to
>> > another part of your webapp from within your wizard)? If so, how do
>> > the potentially orphaned conversations get cleaned up? This is what
>> > causes me to loose sleep at night (yes, I need a life). :-)
>> >
>> >
>> >
>> > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
>> > > I've seen recently some criticism of Tapestry in terms of using
>> > > Hibernate. Problems with lazy loading. I know Tapernate is out
>> > > there, but the docs are pretty thin. I'm using the threadLocal
>> > > version of the much-documented HibernateUtil in a DAO layer. Going
>> > > well. What will Tapernate actually do for me? Does it really solve
>> > > the lazy-loading problem? Are there decent docs?
>> > >
>> > > I would HATE to have to abandon tapestry to work around performance
>> > > problems falling out of non-lazy-loading.
>> > >
>> > > Thanks,
>> > > Bill
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>> --
>> "Budgets are moral documents."
>>
>> -- Ann Richards
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Daniel Tabuenca <dt...@gmail.com>.
So do you have some way of locking all objects to the new session on
the subsequent request? Is this automated in some way? My problem with
the session-per-request-with-detached-objects is that there needs to
be some way to easily identify and re-attach the set of objects that
will be used. I've found it easiest to just keep the session and
reconnect it to the database on the new request. The one problem with
this is if you conversation is long your session might grow too big
since things are not cleaned out of the session even if you
application does not hold any additional references. Maybe ideally it
would be to use some form of AOP to automatically lock objects to the
new session on demand. This seems like it'd be awfully useful, though
I'm not sure how feasible it is to implement.
On 11/4/06, Bill Holloway <bi...@gmail.com> wrote:
> For the lazy loading, what about writing a custom servlet filter as
> recommended in the hibernate docs, one that handles the session for
> you? Let it sit out there in front of Tapestry and manage the
> sessions. I'm leaning toward
> session-per-request-with-detached-objects and letting optimistic
> locking handle the concurrency issues. I'm not so concerned about
> that issue.
>
> My real issue is with the lazy-loading. We'll have objects with some
> pretty hefty fields -- text and maybe blob types -- that I REALLY
> don't want to have loaded if I don't have to.
>
> Cheers,
> Bill
>
> On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> > Bill,
> >
> > The lazy loading problem can't really be solved in a generalized way.
> > But, Tapernate does a lot of work for you. I wouldn't suggest using
> > the property persistence strategies from Tapernate right now. I'm
> > working on a new version that will hopefully be more robust. The main
> > problem that I face is knowing exactly *how* to reattach the detached
> > object to the session when a request comes in. There are a few
> > different scenarios and the problem is knowing which one you're in!
> > Also, if you use merge or update, then your object's state will be
> > persisted at the end of the request (assuming that you leave
> > transaction-per-request on). What if you don't really want the state
> > persisted during that request (you're in the middle of a "wizard"
> > perhaps)? I think the way to go is to use the
> > session-per-conversation pattern, but I'm trying to come up with a
> > good way to specify conversation boundaries. Also, should we support
> > more than one conversation at a time (what if the user clicks to go to
> > another part of your webapp from within your wizard)? If so, how do
> > the potentially orphaned conversations get cleaned up? This is what
> > causes me to loose sleep at night (yes, I need a life). :-)
> >
> >
> >
> > On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > > I've seen recently some criticism of Tapestry in terms of using
> > > Hibernate. Problems with lazy loading. I know Tapernate is out
> > > there, but the docs are pretty thin. I'm using the threadLocal
> > > version of the much-documented HibernateUtil in a DAO layer. Going
> > > well. What will Tapernate actually do for me? Does it really solve
> > > the lazy-loading problem? Are there decent docs?
> > >
> > > I would HATE to have to abandon tapestry to work around performance
> > > problems falling out of non-lazy-loading.
> > >
> > > Thanks,
> > > Bill
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> "Budgets are moral documents."
>
> -- Ann Richards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Bill Holloway <bi...@gmail.com>.
For the lazy loading, what about writing a custom servlet filter as
recommended in the hibernate docs, one that handles the session for
you? Let it sit out there in front of Tapestry and manage the
sessions. I'm leaning toward
session-per-request-with-detached-objects and letting optimistic
locking handle the concurrency issues. I'm not so concerned about
that issue.
My real issue is with the lazy-loading. We'll have objects with some
pretty hefty fields -- text and maybe blob types -- that I REALLY
don't want to have loaded if I don't have to.
Cheers,
Bill
On 11/4/06, James Carman <ja...@carmanconsulting.com> wrote:
> Bill,
>
> The lazy loading problem can't really be solved in a generalized way.
> But, Tapernate does a lot of work for you. I wouldn't suggest using
> the property persistence strategies from Tapernate right now. I'm
> working on a new version that will hopefully be more robust. The main
> problem that I face is knowing exactly *how* to reattach the detached
> object to the session when a request comes in. There are a few
> different scenarios and the problem is knowing which one you're in!
> Also, if you use merge or update, then your object's state will be
> persisted at the end of the request (assuming that you leave
> transaction-per-request on). What if you don't really want the state
> persisted during that request (you're in the middle of a "wizard"
> perhaps)? I think the way to go is to use the
> session-per-conversation pattern, but I'm trying to come up with a
> good way to specify conversation boundaries. Also, should we support
> more than one conversation at a time (what if the user clicks to go to
> another part of your webapp from within your wizard)? If so, how do
> the potentially orphaned conversations get cleaned up? This is what
> causes me to loose sleep at night (yes, I need a life). :-)
>
>
>
> On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> > I've seen recently some criticism of Tapestry in terms of using
> > Hibernate. Problems with lazy loading. I know Tapernate is out
> > there, but the docs are pretty thin. I'm using the threadLocal
> > version of the much-documented HibernateUtil in a DAO layer. Going
> > well. What will Tapernate actually do for me? Does it really solve
> > the lazy-loading problem? Are there decent docs?
> >
> > I would HATE to have to abandon tapestry to work around performance
> > problems falling out of non-lazy-loading.
> >
> > Thanks,
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
"Budgets are moral documents."
-- Ann Richards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by James Carman <ja...@carmanconsulting.com>.
Bill,
The lazy loading problem can't really be solved in a generalized way.
But, Tapernate does a lot of work for you. I wouldn't suggest using
the property persistence strategies from Tapernate right now. I'm
working on a new version that will hopefully be more robust. The main
problem that I face is knowing exactly *how* to reattach the detached
object to the session when a request comes in. There are a few
different scenarios and the problem is knowing which one you're in!
Also, if you use merge or update, then your object's state will be
persisted at the end of the request (assuming that you leave
transaction-per-request on). What if you don't really want the state
persisted during that request (you're in the middle of a "wizard"
perhaps)? I think the way to go is to use the
session-per-conversation pattern, but I'm trying to come up with a
good way to specify conversation boundaries. Also, should we support
more than one conversation at a time (what if the user clicks to go to
another part of your webapp from within your wizard)? If so, how do
the potentially orphaned conversations get cleaned up? This is what
causes me to loose sleep at night (yes, I need a life). :-)
On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> I've seen recently some criticism of Tapestry in terms of using
> Hibernate. Problems with lazy loading. I know Tapernate is out
> there, but the docs are pretty thin. I'm using the threadLocal
> version of the much-documented HibernateUtil in a DAO layer. Going
> well. What will Tapernate actually do for me? Does it really solve
> the lazy-loading problem? Are there decent docs?
>
> I would HATE to have to abandon tapestry to work around performance
> problems falling out of non-lazy-loading.
>
> Thanks,
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-Hibernate
Posted by Daniel Tabuenca <dt...@gmail.com>.
What exactly are the issues with Tapestry and Lazy Loading? I've been
using hibernate and tapestry extensively and have not run into any
lazy loading issue. I really don't see anything in Tapestry that would
make lazy loading any more of an issue than it is in any other web
framework. It all really comes down to how you handle your hibernate
session using the patterns discussed in the hibernate documentation
such as session-per-request or session-per-conversation. At what point
do you actually get lazy loading problems?
On 11/3/06, Bill Holloway <bi...@gmail.com> wrote:
> I've seen recently some criticism of Tapestry in terms of using
> Hibernate. Problems with lazy loading. I know Tapernate is out
> there, but the docs are pretty thin. I'm using the threadLocal
> version of the much-documented HibernateUtil in a DAO layer. Going
> well. What will Tapernate actually do for me? Does it really solve
> the lazy-loading problem? Are there decent docs?
>
> I would HATE to have to abandon tapestry to work around performance
> problems falling out of non-lazy-loading.
>
> Thanks,
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org