• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Some more concurrency fun
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: Some more concurrency fun
      • From: Chuck Hill <email@hidden>
  • Prev by Date: Re: locations of DST information
  • Next by Date: Re: Some more concurrency fun
  • Previous by thread: Re: Strange WOServletAdaptor hanging problem
  • Next by thread: Re: Some more concurrency fun
  • Index(es):
    • Date
    • Thread