On Aug 19, 2007, at 5:53 PM, Paul McNett wrote:
>> These changes are designed to work within the entire framework;
>> i.e., applications, forms, bizobjs and cursors. If you use any
>> single piece of the framework separately, such as a raw cursor,
>> you will have to manage transactions yourself.
> And by managing transactions yourself, do you mean like:
> crs.new()
> crs.Record.cname = "Paul"
> crs.new()
> crs.Record.cname = "Ed"
> crs.beginTransaction()
> crs.save(allRows=True)
> crs.commitTransaction()
That's one possible way. However you do it, though, you have to
manage/verify it yourself.
>> Transactions now happen happen by default when calling biz.save()/
>> saveAll() and biz.delete()/deleteAll(). If for some reason you do
>> not want transactions, you must call them with the parameter
>> startTransaction=False.
> Do we need provisions for this at the UI level... e.g. in dForm.save()
> and dForm.delete()?
We didn't have them before, so I guess that the thinking was that
form generally don't bother with transactions; that's a bizobj/cursor
thing. But I suppose an argument could be made either way.
>> Only one bizobj will begin and commit/rollback. All others do not
>> touch transactions, as they are within the current transaction.
>> Upon a save or delete method being called, the bizobj will request
>> the transaction 'token' from the app. If no other bizobj has
>> started a transaction, it will have True returned from the
>> request, and the bizobj will handle the transaction. If there are
>> related bizobjs who in turn have their save/delete methods called,
>> their requests for the token will be denied, so they will not do
>> anything regarding transactions. When the process is completed in
>> the initial method that requested the token, either a commit or
>> rollback will be called, and the token released.
> I think maybe this would have been better if it were at the connection
> level instead of the app level. IOW, I could have 2 connections to one
> db server and a connection to another db server, and an additional
> connection to a local sqlite database. Transactions for each of these
> connections should be isolated from each other, no?
Yes, but in your example there is no way to create a transaction
that spans multiple connections. IOW, a bizobj for one connection
should never be related to a bizobj for a different connection. Yes,
it's possible in code, but it makes no practical sense.
If you have two connections and bizobjs for each (biz1 and biz2),
you shouldn't nest them or relate them. Instead, you would call:
biz1.save()
biz2.save()
...which would result in:
cxn1.begin()
cursor1.execute("update...")
cxn1.commit()
cxn2.begin()
cursor2.execute("update...")
cxn2.commit()
IOW, it would make no sense to do:
cxn1.begin()
cxn2.begin()
cursor1.execute("update...")
cursor2.execute("update...")
cxn1.commit()
cxn2.commit()
...since a failure/rollback in one would have zero effect on the other.
>> This design eliminates the problem with nested and chained bizobjs
>> starting and/or ending multiple transactions. Only the original
>> bizobj in the process can manage transactions, and only from the
>> method that was originally called.
> Yes, it should let an app developer:
>
> biz.new()
> biz.new()
> biz.saveAll()
>
> ...resulting in:
> begin
> insert
> insert
> commit
Exactly what I had in mind.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
