[Seaside] Transactions, database connections, indices, GOODS and Seaside

C. David Shaffer cdshaffer at acm.org
Wed May 12 22:24:09 CEST 2004


I feel pretty wet behind the ears here.  I appologize for my continued 
newbie questions but...I've been using various patterns in dealing with 
OODB's for a couple years now but in my experiments with Seaside I'm 
finding that I have to either correct it or learn more about Seaside.  
Here's a rough description:

It is inconvenient and expensive for objects to maintain an i-var 
connecting them to every index in which they participate.  So, normally 
when I want to update an index, I retrieve the index explicitly (usually 
it is a near-root object).  However, to be this explicit I need to be 
able to determine what DB transaction/connection/session to ask for the 
root object.  In VisualWorks+WebToolkit+OmniBase we had per-thread 
transactions and per-thread request handling so obtaining the "current 
transaction" was easy.  I don't see how to accomplish this in Seaside.  
I thought that decorations (decorate display and callbacks with a 
database open and throw the transaction into a dynamic binding) would 
work but I'm not so sure since a callback might cause several 
request/response cycles (which each need to have separate transactions 
since I don't want to maintain a txn across a request/response cycle).  
Also, I'm not sure what "scoping" I have which might give access to this 
transaction.  I see that I can't store it in the request or the session 
(which would be a bad choice anyway since it doesn't have the same 
lifetime).  This also bites me during rendering since subcomponents will 
have to search up the component tree to find the current database 
transactions created by some "root" component.

So, how to people deal with this?  Just a push in the right direction 
would be helpful.  Avi, if you recall I asked you about this at your 
tutorial at SS last year and walked away thinking that it would be 
obvious once I got started.  Now, a full year later I can't remember why 
it should be obvious :-)

David

-- 
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com




More information about the Seaside mailing list