• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

FBN determining clientID

 
ahmad namini
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am using RMI as my networking framework.
From my thoughts and design, I don't think that we need to uniquely identify a clientID with a particular lock. Only the queue of lock requests should be consumed in the order in when they were added.
Am I missing something?
Thanks.
 
Perry Board
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What happens after a client has a lock? If you don't know who owns what lock, how can you authorize an update/delete?
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Perry. You're basically abdicating your server's responsibility to track lock to the clients themselves. Mind you, this isn't a bad idea, but I think it goes against the intent of the project.
M
 
ahmad namini
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
good point, but if an update lock is granted, this is effectively a shared lock for reading followed IMMEDIATELY from an exclusive lock for writing. As long as the immediately occurs, then no concurrency issues such as a non-repeatable read can occur.
For delete and add functionality, I plan to escalate the lock area to a database lock. The reason for this is that record numbers, as used as keys in the queue, might become stale.
 
ahmad namini
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i should also say that by using RMI, getting or setting a clientID is not that easy. I can do it, but sockets model which uniquely identifies a client through his/her thread is so much easier.
For clarification, the update transaction broken into a read and then write must occur in the same transaction and be committed to work properly.
 
ahmad namini
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry folks, I forgot one of the basic principles of multithreading. A context switch can occur anytime within the thread.
Thus, if an update lock is to occur, which is a read lock and then a write lock. If the read does occur and then the thread slices out, the write might not be associated with the read, unless I track the transaction owner (clientID) and make sure that the clientID's write occurs after the clientID read.
Is that sound?
Sorry for being so stupid!
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not at all stupid: it sounds like you're using this forum the way it was intented, which is to think aloud and validate your general approach.
But as to that approach, can you break it down a bit: I'm still a little confused on what you're suggesting.
M
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ahmad. Are you using the Connection solution, where each client has its own unique remote object. If so this remote object is all you need to uniquely identify the client.
One of the requirements in the instructions.html states that only the client that locked the record should be able to call unlock for that record.
If you are not using the Connection solution, I'd highly suggest doing a search on this forum for it, and you will find some great discussions on this solution.
Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic