Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

create method

 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have no synchronized my create method as I don't think it needs to be done since my Data class calls an IO class all of whose methods are synchronised. Can I check if this is the right logic for the create method:

 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
provided io.create is sync. i see no issue
 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks Sam.

Have you had a look at my cheakily named '� is stronger than the $' post? No one seems to want to reply to it.
 
Chulwoo Choi
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to make sure. The method's signature should be (according to my instructions doc):
public long createRecord(String [] data)
throws DuplicateKeyException;


As long as you have only one instance of Data corresponding to a database file and only one IO instance associated with the Data instance, I think it should be fine.

Chulwoo
 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chulwoo,

You are right that is the correct signature. However, as a result of asking a different question in a different post I learnt that when we implement DBMain we don't have to throw the same exceptions. The reason I don't want to throw a DuplicateKeyException is because the data file does not store keys at all.

As for instances of Data and the IO class yep of course that is what I intend to do although I have not designed (neither on paper nor in my head) how it's going to fit together yet. But that is my intention.

Actually, there is another issue here. Everywhere I've seen that the usual way of doing an update method is this:



However in my case I'm not exactly sure if a few things are needed.

1. I'm not sure if I need the map of locks because the entire code in all my Data methods are wrapped in a synchronized(map) call anyway so why don't I replace it with a synchronized(this)? Plus I don't see why we are locking records.
2. Secondly I'm beginning to wonder whether I need the synchronized blocks at all in my code since all the methods in my IO class io.update, io.delete, io.create etc are all synchronized. Could I not get away with:



as my code for the update method in Data?
 
Chulwoo Choi
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[olist]
  • In my case, I didn�t have to invoke lock, update or delete, unlock in any synchronized block. A client of Data (for e.g., impl of RMI interface) simply invokes lock (to lock a record and get a cookie), invokes update/delete (using the cookie just obtained), then, invokes unlock. Note my project is B&S in which we use cookies.
  • The synchronized block is needed in your lock method. Note threads waiting for the lock to be available wait inside a while loop in the lock method. Also note the wait() method must be invoked in a synchronized block.

  • [/olist]

    Chulwoo
     
    Chulwoo Choi
    Ranch Hand
    Posts: 65
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sorry [olist] didn't work here
     
    Keith Jones
    Ranch Hand
    Posts: 105
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I'm doing B&S as well but I don't see at all how we are meant to use cookies.
     
    Chulwoo Choi
    Ranch Hand
    Posts: 65
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The one (client/user of Data) who has locked a record is identified by a cookie it (the client) is presenting when invoking update/delete methods.

    To call update/delete method, one must call lock method first to get a cookie and use "that" cookie to proceed. If several threads calls lock method simultaneously, only the first one will get the cookie; others will wait until the first one calls unlock.

    Chulwoo
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic