[Seaside] Omnibase transactions and Seaside transactions

[Cees de Groot]

Avi Bryant wrote:
> IASession>>currentTransaction: should work ok. 

Ok, I'll try.BTW, I fixed a bug in the VW support code for Seaside, 
hopefully a publish later today. WeakValueDictionary was wrong, if you 
can't wait compare #at:put: with Dictionary>>at:put:, it's easy to spot 
the bug.

> Is all of this ReusableRef and invalidating transaction stuff just par for
> the course when using OmniBase?  It all sounds rather messy...
> 
Yup. But that is because OmniBase is a reasonably low-level tool; and 
OmniBase is right, to boot.

If you read object A inside transaction X, I think OmniBase rightfully 
complains when you modify that copy inside transaction Y, not? 
Furthermore, if you have display a list of objects (A, B, C, ...) in 
transaction X, ACID properties justify OmniBase's decision to ignore 
whatever you did inside transaction Y. So if you send off an editor and 
want to display the results of the editing session, you prolly need to 
dump your current transaction and re-read the data. Sounds like just 
following the book to me...

It all comes down on correctly designing transactions, and when you've 
done that, on how to communicate between transactions. I happen to be 
doing this using these ReusableReference beasts, and as soon as you've 
put them were they belong (deep down in your framework code), there's no 
big issue with them. You could use primary keys as well, but the RR's 
work for any OmniBase object (any object? well, no - new, unstored, 
objects won't work...)

At the moment, in the VW WebToolkit environment, I have an OmniBase 
transaction per request. The central request handler starts a 
transaction, processes the request, and commits the transaction. All 
session variables are automatically kept around as ReusableReferences, 
so it's quite transparent in the application layer. However, I don't 
like this transactioning model - I rather scope OmniBase transactions as 
application transactions, like a shopping session, etcetera.

So it turns out to be a bit hairy ;-). But I think that is not a 
property of OmniBase per se. Transactions are complex. Most web 
applications ignore the issue (for starters, by running on top of MySQL 
;-)), but I choose not to.

But if you disagree, please think of a better transaction scoping 
solution; I'm more than happy to test it out...

Regards,

Cees