Thread: How feasible is this?

I'm writing in desperate hope that something like this exists... because
if so, it would make my life a lot easier.  I want to be able to:

a) Roll back a transaction

b) Receive a notification when retrying the exact same transaction might
cause different data to be returned from something that was done up to
the point of the rollback; i.e., some result set, update count, etc.
might be different.

It's okay if (b) is overly sensitive.  For example, one technically
correct (but disappointing) answer would be to get that notification
immediately on the rollback; but that would cause the application to
spin and retry the same transaction in a loop with no delays, which is
hardly ideal to say the least.

Any ideas on doing better than that?

--
Chris Smith

On 21/05/2010 9:22 AM, Chris Smith wrote:
> I'm writing in desperate hope that something like this exists... because
> if so, it would make my life a lot easier.  I want to be able to:
>
> a) Roll back a transaction
>
> b) Receive a notification when retrying the exact same transaction might
> cause different data to be returned from something that was done up to
> the point of the rollback; i.e., some result set, update count, etc.
> might be different.

I don't see any way to do that without polling. You need to be able to
discover every record that the query results are generated from and
watch for one of them to change.

My non-expert feeling is that you could possibly extend a predicate
locking scheme to do this. It's something that'd maybe be possible by
hooking into the predicate locking schemes being being designed to
support true serializability in Pg (see periodic discussion on -hackers)
but those locking schemes aren't in the main PG code yet. Even if they
were, using them for this would be a significant amount of C-coding work
to extend the server.

It might be a good idea to take a few steps back and look at what you
are trying to achieve with this. Why do you want it? What for? What
problem will it solve for you?

--
Craig Ringer

On Fri, 2010-05-21 at 16:08 +0800, Craig Ringer wrote:
> My non-expert feeling is that you could possibly extend a predicate
> locking scheme to do this. It's something that'd maybe be possible by
> hooking into the predicate locking schemes being being designed to
> support true serializability in Pg (see periodic discussion on -hackers)
> but those locking schemes aren't in the main PG code yet.

Thanks for that.  Gives me a place to start looking!

> It might be a good idea to take a few steps back and look at what you
> are trying to achieve with this. Why do you want it? What for? What
> problem will it solve for you?

It's not a typical application-level problem.  I'm playing with the idea
of extending the transactional memory system in the Haskell programming
language so that database access can be done inside of an application
atomic block.  Currently, database access counts as I/O, and therefore
must be done outside of atomic blocks, and this leads to a somewhat
strained programming model for applications combining transactional
memory with databases.

Haskell's transactional memory provides exactly the feature I'm asking
for: specifically, there is a "retry" action, which rolls back a
transaction, blocks until there's some change that makes it likely that
the transaction will behave differently in the future, and then retries
it.  This turns out to be very useful for transactional memory.  Whether
it's useful for database access or not may be an open question, but it
seems very messy to say "don't retry if you've touched the database",
since the point here is to be composable and not make people worry about
the implementation details of some other part of their transactions.

--
Chris Smith