Perhaps a combination of variable isolation types and nested
transactions would solve your problem.
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/
transapp/read.html
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/
transapp/nested.html
Elephant supports all these modes on the BDB data store only. SQL
provides no nesting and I don't believe it supports relaxed
transaction isolation modes.
Ian
On Jun 28, 2007, at 1:29 PM, Mariano Montone wrote:
> There are cases in which a user wants to perform several
operations in
> a transactional way.
Do you have examples? The only cases where my own apps needed several
pages for an operation were creation operation, IIRC. On the other
hand,
there is at least one famous example, namely most online shops
checkout
operation. On Amazon, ISTR you go through 3 or 4 pages to checkout. I
never tried to update my cart while doing that. I wonder how it
behaves.
There's a very simple one which appears almost everywhere in our
framework and is currently unsolved.
Suppose you have an object which has a collection of some other
objects. You want to generate automatically a creator component for
it. We wish we could add and remove items to and from the object at
the creation moment (suppose there's a UI design reason for doing
that). Now, let's complicate things a bit further just to make the
example clearer. Suppose the collection has a domain of possible
objects, for example, represented by the following OQL (Object
Query Language) expression:
select item:CollectionItem from object: EditedObject where not
exists (object.collection as collectionItem where collectionItem is
item). That is to say, the user can choose from a list of items
that makes sense adding to the object's collection (those items
that do not already are in the object's collection). The problems
for doing this are:
1) In a RDBM (MySQL in particular) we cannot reason about a non
existent object (in this case object:EditedObject) if it is not
already inserted in the DB, unless we are in a transaction. We
could do that if we had long transactions and could create the
object in it and then display the creator component.
2) Each addition and removal triggers a request and if we want to
be able use that OQL expression for the UI, then we cannot simply
put things in memory. We would have to implement in-memory querys,
but it is not clear to me how to do it, or if it makes sense. So we
have to add and remove items to the db, each in a short
transaction. Note that the UI depends on putting things on the DB
in order to give feedback to the user because of the way he gets
objects it want's to display (through that query expression).
Although you may think this is a little overcomplicated, this kind
of UI arises in lots of places in my applications and the solution
is to sacrifice that UI design and force the user to create the
object in two stages. First, he creates the object with out
modifying the collection. In the following stage, he is allowed to
modify the collection in a separate screen (after the object has
been created in the db and I can reason about it with that kind of
OQL expressions in the DB).
Mariano
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
