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.
With a synchronous API and threads this wouldn't be a problem, because
we could provide a wrapper function that would bracket your code with
BEGIN TRANSACTION and the appropriate of ROLLBACK or COMMIT depending
on whether you throw an exception, and each thread would be using a
different database connection. But with the async API, you create much
more opportunity for author error.
I think the current model is not really as hard to understand as it
might seem from the spec, which has to be very precise for the sake of
implementations and does not make for a good tutorial.
We should test whether the performance benefits of not using
transactions are significant. If we need to provide both I might
suggest startTransaction or startSqlTransaction that would act like
the current executeSql, and executeSql which acts as currently if
there is a current transaction, but doesn't start one if none is open.
Regards,
Maciej
