[Seaside] Re: Application/Session Objects

[Julian Fitzell]

Well, it is limiting but keep in mind that the user may have multiple 
browser windows open in the same session so if you're going to keep your 
requests open longer than a request you need some way of making sure 
you're using the same one (particularly if you are using db transactions).

You could probably do it by hooking into something like #isolate: or 
writing your own similar method so that you'd have a connection within 
the scope of that call.  I think it's implemented as a decoration these 
days, so the decoration could hold onto the connection.

But I'm getting a bit out of my league here in the sense that I haven't 
acutally tried using seaside with a relational database *and* with db 
transactions, etc.

In our particular case, with the way omnibase works as well, it was 
easier to have the connections handled automatically for us and provided 
in the dynamic scope of every request.  We actually ended up 
implementing essentially our own transactional editing mechanism for the 
model which allowed us to have editing tasks that spanned multiple 
requests but only wrote to the db in the final request.  It all kind of 
grew into something that worked but I don't think we'd claim it was 
ideal in hindsight. :)

Julian

Yanni Chiu wrote:
> It seems to me that using the http req/resp as a transaction
> boundary is an unnecessary and potentially limiting constraint.
> But as a first cut, just go for it.