Support for long conversations in ASP.Net
christianacca
I'm toying with the idea of using long conversations as the session
management model (having a Session span multiple requests) in an
ASP.Net 2.0 app. I have a couple of questions with respect to the
NHibernate/ActiveRecord support in Rhino.Commons:
1. Do you have any experience with using NHibernate long conversations
in ASP.Net? Are there inherent problems/gotchas you've found?
2. Rhino.Commons supports session-in-view model out of the box. Would
it be stretching things too far to use Rhino.Commons with long
conversations? Are there parts of the Rhino.Commons functionality that
just don't fit? For example, does it mean that Automatic Transaction
Management Facility is now unusable?
3. Assuming that Rhino.Commons and "long conversation" in ASP.Net are
not mutually exclusive, are you intending to add this support? If you
aren't intending to add this support, are there obvious problem areas
that you could point out that I would need to be aware of when
implementing it myself?
Thanks
Christian
christianacca
conversations" implemented with *a session spanning mutliple requests*
rather than detattched persistent objects.
C
On 16 Jun, 11:09, christianacca <christian.crowhu...@btinternet.com>
wrote:
> Hi Ayende,
> I'm toying with the idea of using long conversations as the session
> management (having a Session span multiple requests) in an
> ASP.Net 2.0 app. I have a couple of questions with respect to the
> NHibernate/ActiveRecord support in Rhino.Commons:
>
> 1. Do you have any experience with using NHibernate long conversations
> in ASP.Net? Are there inherent problems/gotchas you've found?
> 2. Rhino.Commons supports session-in-view out of the box. Would
Ayende Rahien
The main issue is that the you need to handle the case of the session cache growing very large, if the interaction spans many interactions.
ATM would still work in this scenario, but there may be a perf issue of flushing the session when you have large number of entities in it.
I have no need for this functionality at the moment, but I would accept a patch that would add this functionality.
Initial API ideas:
public class Global : UnitOfWorkApplication
{
public override bool SupportsLongConversations
{
get { return true; }
}
}
The default model is still a session per request, but you can ask:
UnitOfWork.StartLongConversation() and UnitOfWork.EndLongConversation()
At this case, the UoWApplication would put the NH session in the ASP.Net session, and get it back on next request.
Calling the EndLongConversation would dispose the session (at the end of the current request only)
In this case, 1.2 automatic closing of the connection is very helpful.
christianacca
delimit both the start and end of the long conversation. On
reflection, I think I prefer this to what I originally had in mind
(after reading NHibernate in action) which was to always start a long
conversation in a HtmlModule and for a developer to then be explicit
about delimiting the end of that conversation.
Another question: at the moment how do you prefer to accommodate
concurrency issues in a business\user transaction that spans multiple
requests? Do you use detached persistent objects or "do it the hard
way" and pass the version id of the object that has been fetched in
one request, modified by the user and whose changes are now posted
back in a subsequent request?
I must say, its my dislike of supporting detached persistent object
that is biasing me toward long conversations using a session that
spans multiple requests. I like the fact of not having to deal with
reattaching an object from a previous request and running the risk
that the session has already cached that object because of some query
or traversal of an association.
My plan will be to familiarise myself more with the existing Commons
functionality especially the ATM, then create a patch.
C
On 16 Jun, 11:38, "Ayende Rahien" <aye...@ayende.com> wrote:
> Well, there is nothing in Rhino Commons that would prevent such a usage,
> although I would consider it carefully before committing to this approach.
> The main issue is that the you need to handle the case of the session cache
> growing very large, if the interaction spans many interactions.
> ATM would still work in this scenario, but there may be a perf issue of
> flushing the session when you have large number of entities in it.
>
> I have no need for this functionality at the moment, but I would accept a
> patch that would add this functionality.
>
> Initial API ideas:
> public class Global : UnitOfWorkApplication
> {
> public override bool SupportsLongConversations
> {
> get { return true; }
> }
>
> }
>
> The default is still a session per request, but you can ask:
>
> UnitOfWork.StartLongConversation() and UnitOfWork.EndLongConversation()
>
> At this case, the UoWApplication would put the NH session in the
> ASP.Netsession, and get it back on next request.
> Calling the EndLongConversation would dispose the session (at the end of the
> current request only)
> In this case, 1.2 automatic closing of the connection is very helpful.
>
> On 6/16/07, christianacca <christian.crowhu...@btinternet.com> wrote:
>
>
>
> > Hi Ayende,
> > I'm toying with the idea of using long conversations as the session
> > management (having a Session span multiple requests) in an
> > ASP.Net 2.0 app. I have a couple of questions with respect to the
> > NHibernate/ActiveRecord support in Rhino.Commons:
>
> > 1. Do you have any experience with using NHibernate long conversations
> > in ASP.Net? Are there inherent problems/gotchas you've found?
> > 2. Rhino.Commons supports session-in-view out of the box. Would
Ayende Rahien
Because I am working mostly in a web environment, I feel that it is better to use the request model, since it match more closely what is really happening, this means that it goes down to the UI level as well.
Something that I do do is to make some calculation and put that in a cache, and use it later on, but I am careful not to use those entities again, so I don't have the reattaching issues.
christianacca
On 16 Jun, 15:01, "Ayende Rahien" <aye...@ayende.com> wrote:
> Long conversation is really something that is dependent on the context of
> the problem.
> Because I am working mostly in a web environment, I feel that it is better
> to use the request model, since it match more closely what is really
> happening, this means that it goes down to the UI level as well.
> Something that I do do is to make some calculation and put that in a cache,
> and use it later on, but I am careful not to use those entities again, so I
> don't have the reattaching issues.
>
christianacca
http://rhino-tools-dev.googlegroups.com/web/LongConversation.patch?gda=USExikkAAABGK9p1Q79CwCS52zYxKc9-AmW2EBaiajMdQ_Y7NlQhnjZJatNdFkk5z4UBM7pctlaztpCU_8Yr_sHhF8oaDj3AChqcTvw3Z53ycS954JaNwQ&hl=en
A few notables:
1. My intent was to allow the web app developer to mix and match
between session-per-request and long conversation on a use case by use
case basis within the same app rather than having to choose between
mutually exclusive models for a given app
2. I gave up on trying to add some unit tests (I ran out of steam on
trying to get MonoRail.TestSupport up and running) - I hope to revisit
this
3. Didn't like it but had to add a set accessor to
IUnitOfWorkFactory.CurrentSession
4. I didn't know how to implement this set accessor in
ActiveRecordUnitOfWorkFactory
On 16 Jun, 16:38, christianacca <christian.crowhu...@btinternet.com>
wrote:
christianacca
the following transaction handling (for those who are not using ATM):
public class Global : UnitOfWorkApplication
{
public override void UnitOfWorkApplication_EndRequest(object
sender, EventArgs e)
{
try
{
if (!UnitOfWork.InLongConversation)
UnitOfWork.Current.TransactionalFlush();
}
finally
{
base.UnitOfWorkApplication_EndRequest(sender, e);
}
}
}
On 2 Jul, 21:15, christianacca <christian.crowhu...@btinternet.com>
wrote:
> Here's my attempt at an implementation:http://rhino-tools-dev.googlegroups.com/web/LongConversation.patch?gd...
Ayende Rahien
It seems to me like it is too trusting.
christianacca
public override void UnitOfWorkApplication_EndRequest(object
sender, EventArgs e)
{
try
{
if (HttpContext.Current.Server.GetLastError() == null
&& !UnitOfWork.InLongConversation)
UnitOfWork.Current.TransactionalFlush();
}
finally
{
base.UnitOfWorkApplication_EndRequest(sender, e);
}
}
Unless I'm mistaken (quite possibly) the above would mean that if an
exception has bubbled up no attempt will be made to commit the
transaction. The handling in base.UnitOfWorkApplication_EndRequest
will result in the session being disposed (and the long conversation
ended).
C
On 13 Jul, 16:37, "Ayende Rahien" <aye...@ayende.com> wrote:
> I would serious suggest against this pattern, what about errors / exceptions
> along the way?
> It seems to me like it is too trusting.
>
> > > > > > > > conversations? Are there parts of the Rhino.Commonsfunctionality that
Ayende Rahien
This is something worth testing, but what would happen if you call Response.End() or Response.Redirect() in such a case?
I added error handling logic:
public override void UnitOfWorkApplication_EndRequest(object
sender, EventArgs e)
{
try
{
if (HttpContext.Current.Server.GetLastError () == null
&& !UnitOfWork.InLongConversation)
UnitOfWork.Current.TransactionalFlush();
}
finally
{
base.UnitOfWorkApplication_EndRequest (sender, e);
christianacca
"Here's a cool new behavior in ASP.NET 2.0: Response.End() no longer
kills post Application Handler events! " (see http://west-wind.com/weblog/posts/494.aspx)
So the implementation (subject to more thorough testing) is
acceptable, yes?
C
On 13 Jul, 17:05, "Ayende Rahien" <aye...@ayende.com> wrote:
> That would work, but I guess that I am not really fond of it happening in
> such a way.
> This is something worth testing, but what would happen if you call
> Response.End() or Response.Redirect() in such a case?
>
> On 7/13/07, christianacca <christian.crowhu...@btinternet.com> wrote:
>
>
>
> > I added error handling logic:
>
> > public override void UnitOfWorkApplication_EndRequest(object
> > sender, EventArgs e)
> > {
> > try
> > {
> > if (HttpContext.Current.Server.GetLastError() == null
> > && !UnitOfWork.InLongConversation)
> > UnitOfWork.Current.TransactionalFlush();
> > }
> > finally
> > {
> > base.UnitOfWorkApplication_EndRequest(sender, e);
christianacca
On 13 Jul, 17:18, christianacca <christian.crowhu...@btinternet.com>
wrote:
> Just googled Response.End() and found this
>
> "Here's a cool new behavior in ASP.NET 2.0: Response.End() no longer
> kills post Application Handler events! " (seehttp://west-wind.com/weblog/posts/494.aspx)