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

Reply via email to