[Seaside] Omnibase transactions and Seaside transactions

[Cees de Groot]

I'm trying to get my head around combining OmniBase transactions and 
Seaside transactions, with not much luck sofar.

The issue is that persistent objects in OmniBase only are valid in the 
context of a transaction. When you mark them dirty, OmniBase looks for 
the OID of the object which it only finds when the object was read from 
the database in the current transaction ('current' as in 'found in the 
process->transaction dictionary'). So if you accidentally read an object 
in Txn A and then modify it in Txn B, you get an error.

A case study: a list of news items (for a sort of weblog page). There 
are two pages - the list of items, and an edit page for a single item.

I'm using a subclass of IASession that sets up an OmniBase transaction 
in aboutToView, so that the current process always has a transaction 
(IIRC, every web hit of a session is done in the same process, not?). So 
the list of items is read and rendered inside the default transaction. 
Now, I want to edit a single item so I click on the edit link of one of 
the items.

edit: anItem
   session isolate: [NewsItemEditor new item: anItem]

is the basic idea. My IASession subclass does a transaction for the 
isolate as well. In the actual code, there is some wrapping going on: 
because 'anItem' will not be valid inside the new transaction that is 
active inside the #isolate:, I wrap its OID inside a proxy; when the 
object is accessed in the new transaction, its DNU handler grabs the 
real object through the OID (so the object is now read and therefore 
valid within the new transaction) and forwards all messages to it. 
Somehow, the object is historically called a 'ReusableReference' 
(reference to an object reusable accross transactions):

edit: anItem
   | ref |
   ref := ReusableReference for: anItem
   session isolate: [NewsItemEditor new item: ref]

It all works reasonably well, but it is a long shot from all the 
transparency that Seaside offers. And it gets worse: if you edit a news 
item, and you press 'Save', you return from the #isolate: block back in 
the same transaction - of course, OmniBase has all the objects cached so 
when you return from the edit to the news item list, you don't see any 
of your changes.

Solution: close the OmniBase transaction and fire up a new one at the 
end of the #isolate: - to that end, I have overridden #closeTransaction 
to rollback and nillify the OmniBase transaction; the next #aboutToView 
will then start a new transaction and the changes show up.

Nice, but now you have: (show list in txn A) (edit item in txn B) (show 
list in txn C), and guess what happens if you press back twice (going 
back to the first list, in txn A) and then press a button - OmniBase 
will barf because txn A was closed so the seaside transaction context is 
in fact invalid.

Short summary: it's a bit of a mess :-). Any hints on whether this is 
resolvable are more then welcome...

Regards,

Cees