Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Simultaneous update of one record

 
Anton Brass
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey there,

I'm nearly finished the implementation of my UrlyBird project.

Now I'm wondering about the situation if two threads (clients) try to update the same record.

My implementation handles it this way:

  • Client 1 checks if record A exists (true)
  • Client 1 locks record A
  • Client 2 checks if record A exists (true)
  • Client 2 tries to lock record A (waiting)
  • Client 1 updates record A
  • Client 1 release lock of record A
  • Client 2 checks if record A exists (true)
  • Client 2 locks record A
  • Client 2 updates record A with another value
  • Client 2 release lock of record A


  • I have no mechanism that checks if the record was changed since Client 2 tries to get the lock on it. Only if the record is deleted in between the waiting a RecordNotFoundException is thrown...

    Two questions:

    1) Should I check if the record was changed and throw a new RuntimeException. If so, what's the best way, since i can imagine a new map or reading the record before update and check again.
    2) Is is ok to extend the Sun interrface with own RuntimeExceptions?


     
    Roberto Perillo
    Bartender
    Posts: 2271
    3
    Eclipse IDE Java Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Howdy, Anton!

    Well champ, it looks like your schema is almost correct. The only thing that I think that has to be changed is, when client 2 locks record A, you have to verify if the client ID field is still empty; if it isn't, it was booked to another customer. Since these verifications are to be done in the business layer, then you can throw an exception, say, RoomAlreadyBookedException in you bookMethod(). So, if it is empty, then you update and release; otherwise, you throw the exception and release the lock in a finally block.

    2) Is is ok to extend the Sun interrface with own RuntimeExceptions?


    Hum... how would that be? Since RuntimeExceptions aren't checked, then they don't have to be listed in the method's signature...
     
    Anton Brass
    Greenhorn
    Posts: 25
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    1) Ok, I added a bookRecord method to my DataAccessService, before I only had a general update() method, where I didn't want to check everything.

    2) E.g., I added a "FileAccessException" to my imeplementation of the interface:

    public void update(int pRecordNumber, String[] pData, long pCookie)
    throws RecordNotFoundException, SecurityException,FileAccessException {
    }

    If something goes wrong during changing the file (IOException) I don't want to throw a "RecordNotFoundException" since it is not the case. Or is it a big mistake to add a RuntimeException for this purpose?
     
    Rafal Kawecki
    Ranch Hand
    Posts: 30
    Eclipse IDE Java Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,

    since my problem/approach seems to be similar I will my post my question here.

    Have any of you synchronized update/book method in your business logic? It seems to be necessary (at least in my opinion) because there cannot be any updates to a record between the moment I made myself sure that it had not been updated and when I book it.

    So I was planning to implement something like this (db is an instance of a Data class (singleton)):

    Keep in my that all methods in Data class are synchronized as well.
    I've been thinking to use synchronized(this) or pblic void synchronized book(uRoom newRoom) but then I would need to grab two locks and thanks to this solution only lock for the db is required.

    Thanks in advance

    Rafal
     
    Jonathan Elkharrat
    Ranch Hand
    Posts: 170
    Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Rafal:
    synchonizing the whole method make the lock/unlock useless.
    the same question was asked here by Robert Benson.


    so if you are afraid the record would be booked between the read and locking, how can you assure this record (and only this,
    making the whole method synchronized will block the whole database) is not modified?


    see also this question in the FAQ...
     
    Rafal Kawecki
    Ranch Hand
    Posts: 30
    Eclipse IDE Java Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Jonathan Elkharrat wrote:
    synchonizing the whole method make the lock/unlock useless.

    I agree in 100%, my big big mistake. Thanks for pointing that out.
    Jonathan Elkharrat wrote:
    so if you are afraid the record would be booked between the read and locking, how can you assure this record (and only this,
    making the whole method synchronized will block the whole database) is not modified?

    I can lock it first
     
    Jonathan Elkharrat
    Ranch Hand
    Posts: 170
    Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    that's the spirit...
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic