- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 17 Oct 2007 11:49:22 -0700
On Oct 17, 2007, at 9:14 AM, Brady Eidson wrote: > > 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 I don't think you would typically need to use BEGIN, COMMIT or ROLLBACK with the current API, but perhaps the spec should define what happens if you do. In any case, using the easiest path to transactions would not have either of these pitfalls. Regards, Maciej
Received on Wednesday, 17 October 2007 11:49:22 UTC