How to stitch multiple events into one transaction with acid-state?

[Maxim Savchenko]

Hello!

I have a problem with expressing my algorithm in acid-state terms. That's what I'm trying to do:

x <- query' acidStorage (SomeQuery ...)

y <- someReasoningThatNeedsIO x

update' acidStorage (SomeUpdate y ...)

The problem is, that I need this query+update to be one atomic transaction. Is this possible with acid-state alone or I need to write transaction mechanics myself?

[David Himmelstrup]

Doing this would be fairly tricky with AcidState.

-- 

David Himmelstrup

--
You received this message because you are subscribed to the Google Groups "HAppS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to happs+un...@googlegroups.com.
To post to this group, send email to ha...@googlegroups.com.
Visit this group at http://groups.google.com/group/happs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeremy Shaw]

Hello,

I'm afraid you can't do that (for good reasons I won't go into unless you ask).

Instead, you will need to structure things so that it is ok that it is
not a single transaction. The first thing to ask yourself is if it
really matters if the database changes between the query and the
update. I've found that sometimes I assume things need to be a single
transaction, and then realize they do not when I look closer.

If it does matter, then next thing to ask yourself is if you can
modify your approach so that it doesn't matter.

Assuming that is not possible and the update only makes sense if the
result of the query has not changed, you could do something like:

retry $ do
x <- query' acidStorage (SomeQuery ....)
y <- someReasoningThatNeedsIO x
update' acidStorage (SomeUpdate x y)

The idea is:

1. do the query
2. calculate the IO result
3. pass the calculated value and the original query value to the
update function
4. SomeUpdate checks that the query value has not changed. If it has,
the update fails, if it hasn't then the update is applied.
5. retry checks if the update passed or failed and retries if it failed

This is a bit like how STM works -- assume everything is going to be
ok, and if it isn't just start over and try again. (At least that's
how I think STM works.. it's been a while).

This assumes that it is ok to run the IO operation multiple times. It
assumes a couple other things too -- such as being able to confirm
that the two query results are the same.

I used to run into this type of situation more often, and somehow I
have changed my approach so that it doesn't really come up anymore.

But, I think that some retry operations might be a nice addition to
acid-state. We definitely can not allow IO in the update/query events
themselves. But, we could provide a bit more infrastructure to support
IO outside the update/query events.

It's a bit hard to provide a great solution without seeing your code.
If you want to discuss your code in more depth, we can try to figure
out a good solution, and then, if needed, add some extra helper
functions to acid-state.

- jeremy

[Maxim Savchenko]

Thank you a lot for your detailed answer!

After thinking a bit, I realised, that such feature is not easy to implement. Withouth knowledge about data structures that I'm storing inside, the only thing acid-state could do would be global lock for each transaction - obviously not a good solution...

I think, I'll try to use your retry approach - things I request are mostly Eq and any non-retryable side-effects probably can be postponed till update succeeds. The only thing I'm aftaid off - unpredictable retry count under heavy load. But this is problem of future me and will be solved later :-)

But if man can dream - I imagine structure-awareness layer over acid-state. Something with lens-based interface maybe - so it issues only needed local locks automaticly when data are accessed in the transactions... You know - this could be killer-feature, shooting acid-state ahead of the mainstream databases.

вторник, 26 марта 2013 г., 21:57:21 UTC+4 пользователь Jeremy Shaw написал: