Re: Some more concurrency fun
Re: Some more concurrency fun
- Subject: Re: Some more concurrency fun
- From: Anjo Krank <email@hidden>
- Date: Mon, 28 Jan 2008 22:40:23 +0100
I dimly remember a post a year ago from Mike dealing with this? It had
to do with notifications getting sent and updating snapshots from
under the transaction.
Cheers, Anjo
Am 28.01.2008 um 22:36 schrieb Chuck Hill:
On Jan 28, 2008, at 1:30 PM, Miguel Arroz wrote:
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:
<pastedGraphic.pdf>
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:
<pastedGraphic.pdf>
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.
Too lazy to read that :-) but this should not be the result.
To avoid this, I must change the transaction isolation level to
serializable, right? Or I am missing something?
Here is what I use for FrontBase:
jdbc:FrontBase://localhost/DatabaseName/isolation=read_committed/
locking=optimistic
That produces the correct result.
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?
It calls it during saveChanges(), after all the operations have been
converted to EOAdaptorOperations. That is, the transaction only
lasts for part of the execution time of saveChanges().
2) Why don't BEGIN and COMMIT appear in the SQL log? Not even in
the DB log?
That might be PG. I do see them in the log for FrontBase.
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).
The transaction is held for the shortest possible time (relative to
EOF architecture).
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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
_______________________________________________
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