Some more concurrency fun
Some more concurrency fun
- Subject: Some more concurrency fun
- From: Miguel Arroz <email@hidden>
- Date: Mon, 28 Jan 2008 21:30:05 +0000
Hi!
Today I suddenly remembered that I have another problem in my
concurrent transactions. As usual, I want to check with you because I
might be seeing this all wrong, and I also have some questions I
don't know the answers too.
FYI, I'm using PostgreSQL. This is important because this problem
is DB specific (I guess).
The problem is this: let's say I have an entity, BankAccount (how
original!) with a balance field, optimistic locked. I grab my account
in two different application instances, change their value, and save.
I'll get an OL exception on the instance that tried to save in the
last place. So, we have this:
Attachment:
pastedGraphic.pdf
Description: Adobe PDF document
The gray bars on save represent the several SQL commands the app
has to send to the DB so that the save can occur (in this case,
begin, update blablabla where accountId = X and balance = y, commit).
In this case, everything goes fine.
Now, let's look at the gray bars (they are not there by
accident!). Let's now suppose the saving stages in the previous
scheme happen concurrenty. If we assume the first saving stages of
both instances happen at the same time, we can have this:
Attachment:
pastedGraphic.pdf
Description: Adobe PDF document
From what I undertand from the PostgreSQL documentation,
specifically <http://www.postgresql.org/docs/8.2/interactive/
mvcc.html>, this will NOT cause any errors and both transactions will
commit. The result? There goes 100 euros... the final result is 300
when it should be 400.
To avoid this, I must change the transaction isolation level to
serializable, right? Or I am missing something?
This leads to another potential problem: performance. And here's
my two questions:
1) When exactly does WO send the BEGIN command to the database? On
the first operation of an EC? Or when saveChanges() is called?
2) Why don't BEGIN and COMMIT appear in the SQL log? Not even in
the DB log?
I'm worried because if the BEGIN happens on the first operation of
an EC, there will be tons of long-living dumb transactions pending,
which in serializable mode means PostgreSQL has to maintain all the
intermediate stages of ALL the db changes in memory (sort of, there
are some optimizations).
Yours
Miguel Arroz
Miguel Arroz
http://www.terminalapp.net
http://www.ipragma.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden