- From: Brady Eidson <beidson@apple.com>
- Date: Wed, 17 Oct 2007 09:14:42 -0700
On Oct 17, 2007, at 1:41 AM, Maciej Stachowiak wrote: > > On Oct 17, 2007, at 12:33 AM, Brady Eidson wrote: > >> An admirable goal - one that I agree with. Which is why I think >> the wisdom of the implicit transaction is dubious. Developers that >> will be using SQL will know they can say "BEGIN TRANSACTION;" and >> "COMMIT;" or "ROLLBACK;" so the utility of having transactions will >> not be lost. Ditching it would help thin the API further, clearing >> up this confusion and complexity. > > > Downsides to this approach: > > - You could only have one transaction in flight at once, so you'd > have to do scheduling in the app code if a transaction-starting UI > operation happens while you already have a transaction in progress. > Otherwise multiple transactions would get scrambled. (Or else the > API layer could parse your statements and understand when you have > opened a transaction to still implicitly assign statements in your > callbacks to the transaction, but I am not sure this is a > simplification overall.) > > - An author mistake (like doing something that causes an exception > in the callback) means a stuck lock, quite possibly ruining the > whole session. I agree these are potential downfalls, but ones that already exist with the current spec. We have the implicit transaction already, so a performance-minded developer starting their own transaction might already trigger this scenario ~Brady
Received on Wednesday, 17 October 2007 09:14:42 UTC