RE: [trails-dev] Re: [trails-users] session-per-conversation

[nhhockeyplayer]

Can someone give use-case examples of multiple windows implementation ? I have not followed this and wondering what it is all about.

Best regards
Ken in nashua

---

Date: Thu, 18 Oct 2007 01:21:50 -0700
From: kalle.o.korhonen@...
To: dev@...
Subject: Re: [trails-dev] Re: [trails-users] session-per-conversation

On 9/28/07, Alejandro Scandroli <alejandroscandroli@...> wrote:

On 9/28/07, Kalle Korhonen <kalle.o.korhonen@...> wrote:
> Now that Alejandro tells me he managed to implement multiple windows
> (TRAILS-63) by serializing the whole CallbackStack to the url (from where
> it's only a "short" hop away of a proper implementation following the
> "squeezer" pattern) and we are almost done with Trails 1.1 release, I feel
> it's the right time to re-open the discussion for implementing long
> conversations.
    The multiple windows implementation changes a lot the way we work
with pages and with the objects in them. It introduces some new
concepts and practices that may not be fully compatible with the way
we are doing things now. Next week I will checkin what I have and I
will start a wiki page to document these changes.

I see you've been busy with TRAILS-63 in the branch, and certainly multiple windows is a corner stone for session-per-conversations. One of the key things for session-per-conversations is persisting objects in session (or client) in a way they don't collide which your implementation for multiple window support undoubtedly solves. So I'll be more than happy to wait until you are done before we can really move forward with implementing this.

> At the same time, we have to keep our eye on Tapestry 5
> development. Does it make sense for us to invest time and effort in features
> that'll be available in it later? Howard is on record for saying he's going
> to provide integration with WebFlow as Tapestry 5's session-per-conversation
> implementation.

    I think it does make sense, as long as you see a use for it. BTW,
about Tapestry5 I want to start merging some T5 in my apps using the
same Trails backend, I will comment more on this subject later.

Yes, I'm continuously on the verge of doing this but I keep thinking it's a little too soon for me after seeing how many things are still missing for T5. T5 of course brings a lot on the table regarding ease-of-development, but not so much regarding the power and expressiveness compared to T4 and Hivemind, currently even badly lacking in some areas. And yes, certainly I see a use for session-per-conversation as it can have an high impact on the performance and it's something that 2-tier architectures just cannot do. At the same time, I would like to do something more in spirit of Trails than a Spring webflow/ Seam-style explicit conversations.

> Consider a familiar use case (at least to me) where you are on a
> travel site, and got your search results in one window. Then you'd like to
> open a new browser window just to investigate an alternative route or time.
> After seeing the results, you decide the first one looked better and try to
> select an item. In most cases, you'd be required to re-enter your search
> criteria, or you might even get the wrong item corresponding to the results
> from your earlier search! In Trails, multiple window support would solve the
> problem, but with detached objects.
   It's worst than that. The objects are not even detached, they are
compressed down to EntityIdentity(ies) and reloaded from the DB on the
next request.

Sure,  that's part of session-per-request, I just meant to imply the objects become detached as soon as the request is processed.

> With session-per-conversation, the problem is how do you end a

> session if a window is abandoned? Now that we live in this ajaxified word,
> what if each Trails window would just keep notifying the server that it
> still exists? With this "keep-alive" you could easily remove sessions of
> abandoned conversations and even track how many parallel conversations you
> want to allow the user to have. I hardly think that a slowly refreshing, say
> after every few minutes - or possibly configurable, ajax-request could put
> any meaningful stress on the system, considering the server anyways needs to
> serve so many requests with each page refresh. However, it'll make a big
> impact on memory usage since cleaning up the abandoned sessions for
> conversations would be separate from the expiration of servlet session.

   You can also use onCloseWindow event hooks. I don't understand the
memory issues, if we keep using a sessions pool we just need to return
the session to the pool. am I wrong? hmmmm I know I'm missing
something obvious.

Well, yes, on onCloseWindow would get us somewhere but in my mind not far enough. For example, consider multiple windows that participate in the same conversations. Would we end the conversation if one of them closes? To really be able to end the conversation, we'd need to track how many windows are open. We could do that, but it's complex and not bullet-proof. One easy way out is to have one window limit per conversation but that approach might be too inflexible. Another problem that the close event doesn't solve are stale windows that are left open but not actively used. I think this is common for example in the above scenario where user is doing multiple parallel searches. I'm imaging that if we implement session-per-conversation in a generic way we need to be much more conservative about managing memory than the explicit conversation patterns are. So,  the keep-alive could for example be used to end session if no client-side activity has been detected, e.g. user is not editing a form. In a way, session-per-conversation trades memory for performance, but it's difficult to fit make that model work for high user count, high-scalabilty applications where Tapestry shines.

I think one of the reasons the 2-tier architectures are still so prevalent because they are very good at keeping the memory profile low (besides being simpler of course). Session-per-request does the same as long as the the JVM works efficiently enough cleaning up those detached objects. However, the garbage collection performance is one of the major scalability bottlenecks with these newer architectures. Especially JSF is notorious about creating hundreds, even thousands of objects every time while rendering a page, which causes overloading of the garbage collector even if the object creation itself is blazingly fast. Session-per-request adds load to the system the same way, but the current conversation models use memory rather liberately and easily leave unended conversations behind that leads to ballooned-up sessions and excessive memory consumption as the used persistent instances of abandoned conversations would stay in memory till (servlet) session expires. If we can manage the conversations length in seconds or a few minutes at most, we'll get all the benefits without penalties.

> In principle, how would this sound? Worth to pursue, any immediate problems
> that you see? If we have a general agreement, I'll open an issue for it and
> tentatively schedule the implementation for 1.2 Trails.

    It's definitively worth it. I would like us to sync up to make
sure we don't end up with incompatible implementations. I would also
like to keep the old OpenSessionInView pattern around (if possible) so
users can have a choice.

Sure, I'm just fleshing out the possible implementation so far. But the way I see it, the goal is to obsolete OpenSessionInView completely if at all possible. Of course, OpenSessionInView doesn't mean session-per-request in principle, but in practice it often leads to it as the only possibility as discussed in the posts I linked in previously. The situation is further complicated by the fact that there are different kinds of view scenarios, in some of which it's beneficial to open the session right away (for example the search use case with lazy-loaded objects) and in some cases you might want to open a different session instead ( e.g. for editing). Furthermore, it might be a better idea to use detached object for editing as argued in other threads (http://forum.springframework.org/archive/index.php/t-41582.html , don't think I posted this link earlier). The only certain use case for session-per-conversation is browsing collections of objects. So, all-in-all, I'm not certain this can be solved in a generic way, but it'll be interesting to try.

Kalle

---

Peek-a-boo FREE Tricks & Treats for You! Get 'em!

[Alejandro Scandroli]

Hi Ken,

I'm still working on it, I'm working on separate branch
(ascandroli-20071009-TRAILS63).

Next week I will start a wiki page to talk about the implementation.

Alejandro.

On 10/18/07, Ken nashua <nhhockeyplayer@...> wrote:

>
>  Can someone give use-case examples of multiple windows implementation ? I
> have not followed this and wondering what it is all about.
>
> Best regards
> Ken in nashua
>
>
>  ________________________________
>  Date: Thu, 18 Oct 2007 01:21:50 -0700
> From: kalle.o.korhonen@...
> To: dev@...
> Subject: Re: [trails-dev] Re: [trails-users] session-per-conversation
>
>
> On 9/28/07, Alejandro Scandroli <alejandroscandroli@...> wrote:
>
> On 9/28/07, Kalle Korhonen <kalle.o.korhonen@...> wrote:
> > Now that Alejandro tells me he managed to implement multiple windows
> > (TRAILS-63) by serializing the whole CallbackStack to the url (from where
> > it's only a "short" hop away of a proper implementation following the
> > "squeezer" pattern) and we are almost done with Trails 1.1 release, I feel
> > it's the right time to re-open the discussion for implementing long
> > conversations.
>     The multiple windows implementation changes a lot the way we work
> with pages and with the objects in them. It introduces some new
> concepts and practices that may not be fully compatible with the way
> we are doing things now. Next week I will checkin what I have and I
> will start a wiki page to document these changes.
>
> I see you've been busy with TRAILS-63 in the branch, and certainly multiple
> windows is a corner stone for session-per-conversations. One of the key
> things for session-per-conversations is persisting objects in session (or
> client) in a way they don't collide which your implementation for multiple
> window support undoubtedly solves. So I'll be more than happy to wait until
> you are done before we can really move forward with implementing this.
>
>
> > At the same time, we have to keep our eye on Tapestry 5
> > development. Does it make sense for us to invest time and effort in
> features
> > that'll be available in it later? Howard is on record for saying he's
> going
> > to provide integration with WebFlow as Tapestry 5's
> session-per-conversation
> > implementation.
>
>     I think it does make sense, as long as you see a use for it. BTW,
> about Tapestry5 I want to start merging some T5 in my apps using the
> same Trails backend, I will comment more on this subject later.
>
> Yes, I'm continuously on the verge of doing this but I keep thinking it's a
> little too soon for me after seeing how many things are still missing for
> T5. T5 of course brings a lot on the table regarding ease-of-development,
> but not so much regarding the power and expressiveness compared to T4 and
> Hivemind, currently even badly lacking in some areas. And yes, certainly I
> see a use for session-per-conversation as it can have an high impact on the
> performance and it's something that 2-tier architectures just cannot do. At
> the same time, I would like to do something more in spirit of Trails than a
> Spring webflow/ Seam-style explicit conversations.
>
>
> > Consider a familiar use case (at least to me) where you are on a
> > travel site, and got your search results in one window. Then you'd like to
> > open a new browser window just to investigate an alternative route or
> time.
> > After seeing the results, you decide the first one looked better and try
> to
> > select an item. In most cases, you'd be required to re-enter your search
> > criteria, or you might even get the wrong item corresponding to the
> results
> > from your earlier search! In Trails, multiple window support would solve
> the
> > problem, but with detached objects.
>    It's worst than that. The objects are not even detached, they are
> compressed down to EntityIdentity(ies) and reloaded from the DB on the
> next request.
>
> Sure,  that's part of session-per-request, I just meant to imply the objects
> become detached as soon as the request is processed.
>
>
> > With session-per-conversation, the problem is how do you end a
> > session if a window is abandoned? Now that we live in this ajaxified word,
> > what if each Trails window would just keep notifying the server that it
> > still exists? With this "keep-alive" you could easily remove sessions of
> > abandoned conversations and even track how many parallel conversations you
> > want to allow the user to have. I hardly think that a slowly refreshing,
> say
> > after every few minutes - or possibly configurable, ajax-request could put
> > any meaningful stress on the system, considering the server anyways needs
> to
> > serve so many requests with each page refresh. However, it'll make a big
> > impact on memory usage since cleaning up the abandoned sessions for
> > conversations would be separate from the expiration of servlet session.
>    You can also use onCloseWindow event hooks. I don't understand the
> memory issues, if we keep using a sessions pool we just need to return
> the session to the pool. am I wrong? hmmmm I know I'm missing
> something obvious.
>
> Well, yes, on onCloseWindow would get us somewhere but in my mind not far
> enough. For example, consider multiple windows that participate in the same
> conversations. Would we end the conversation if one of them closes? To
> really be able to end the conversation, we'd need to track how many windows
> are open. We could do that, but it's complex and not bullet-proof. One easy
> way out is to have one window limit per conversation but that approach might
> be too inflexible. Another problem that the close event doesn't solve are
> stale windows that are left open but not actively used. I think this is
> common for example in the above scenario where user is doing multiple
> parallel searches. I'm imaging that if we implement session-per-conversation
> in a generic way we need to be much more conservative about managing memory
> than the explicit conversation patterns are. So,  the keep-alive could for
> example be used to end session if no client-side activity has been detected,
> e.g. user is not editing a form. In a way, session-per-conversation trades
> memory for performance, but it's difficult to fit make that model work for
> high user count, high-scalabilty applications where Tapestry shines.
>
> I think one of the reasons the 2-tier architectures are still so prevalent
> because they are very good at keeping the memory profile low (besides being
> simpler of course). Session-per-request does the same as long as the the JVM
> works efficiently enough cleaning up those detached objects. However, the
> garbage collection performance is one of the major scalability bottlenecks
> with these newer architectures. Especially JSF is notorious about creating
> hundreds, even thousands of objects every time while rendering a page, which
> causes overloading of the garbage collector even if the object creation
> itself is blazingly fast. Session-per-request adds load to the system the
> same way, but the current conversation models use memory rather liberately
> and easily leave unended conversations behind that leads to ballooned-up
> sessions and excessive memory consumption as the used persistent instances
> of abandoned conversations would stay in memory till (servlet) session
> expires. If we can manage the conversations length in seconds or a few
> minutes at most, we'll get all the benefits without penalties.
>
>
> > In principle, how would this sound? Worth to pursue, any immediate
> problems
> > that you see? If we have a general agreement, I'll open an issue for it
> and
> > tentatively schedule the implementation for 1.2 Trails.
>
>     It's definitively worth it. I would like us to sync up to make
> sure we don't end up with incompatible implementations. I would also
> like to keep the old OpenSessionInView pattern around (if possible) so
> users can have a choice.
>
> Sure, I'm just fleshing out the possible implementation so far. But the way
> I see it, the goal is to obsolete OpenSessionInView completely if at all
> possible. Of course, OpenSessionInView doesn't mean session-per-request in
> principle, but in practice it often leads to it as the only possibility as
> discussed in the posts I linked in previously. The situation is further
> complicated by the fact that there are different kinds of view scenarios, in
> some of which it's beneficial to open the session right away (for example
> the search use case with lazy-loaded objects) and in some cases you might
> want to open a different session instead ( e.g. for editing). Furthermore,
> it might be a better idea to use detached object for editing as argued in
> other threads
> (http://forum.springframework.org/archive/index.php/t-41582.html
> , don't think I posted this link earlier). The only certain use case for
> session-per-conversation is browsing collections of objects. So, all-in-all,
> I'm not certain this can be solved in a generic way, but it'll be
> interesting to try.
>
> Kalle
>
> ________________________________
> Peek-a-boo FREE Tricks & Treats for You! Get 'em!

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email