• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX Contractors: Data instances and locking

 
David Lindquist
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Everyone,
In my Data class, I ensure that only one instance is created per db file. I see this as having the following advantages:
  • it minimizes the number of Data objects created.
  • it prevents the meta data of the db file from being parsed multiple times unnecessarily.
  • it ensures that only one FileChannel will do the I/O on a given db file.


  • However, I'm now running into a problem with the locking mechanism. The lock method in DBMain states that it
    Locks a record so that it can only be updated or deleted by this client.

    If all clients share a single Data instance for a particular db file, how then can the db know which client is requesting a lock, given that the lock method takes only a single record number parameter? It seems that the obvious solution would be to allow a new Data instance for every client, but then all the advantages listed above are lost.
    I'm trying to keep things simple by confining lock management to the Data class (via a static HashMap) as well as reduce the number of Data instaces created (and the number of "helper" classes needed), but these seem to be mutually exclusive.
    I have that sinking feeling I'm missing something obvious. Any ideas?
     
    Tony Collins
    Ranch Hand
    Posts: 435
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I don't think you do lose those advantages and I think some aren't really advantages.

    it minimizes the number of Data objects created.
    it prevents the meta data of the db file from being parsed multiple times unnecessarily.
    it ensures that only one FileChannel will do the I/O on a given db file.

    Yes it does minimise the data objects but why is this an advantage.
    The meta data can be obtained by a static function when the server is started. So this isn't really an advantage.
    Multiple File Channels can access a file concurrently.
    Tony
    [ August 11, 2003: Message edited by: Tony Collins ]
     
    David Lindquist
    Greenhorn
    Posts: 6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Tony,
    Yes, I suppose these are not necessarily advantages per se, but rather design preferences of mine (I prefer "single" over "multiple" generally). But your point is well taken.
    It seems that providing a single Data instance per db file is a popular choice here at JR, judging by some threads I've read. I am curious how those poeple who went this route approached the problem I mentioned above. But then again, maybe this "problem" is only due to my lack of experience in application design
     
    Jim Yingst
    Wanderer
    Sheriff
    Posts: 18671
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Does your lock method return a "cookie"? If so, you can probably assume that only the client that locked the record will know the cookie value that's required to unlock (or otherwise use) a locked record. It's like a password. If you're using cookies, you probably don't need any additional authentication to establish that the client attempting an update is the cone that previously locked the record. However, some assignments don't require cookies. And even if you do use cookies, you may still find it useful/necessary to have a some sort of class in which each instance is associated with a different client. This is particularly true if you want to handle client disconnects or elaborate deadlock prevention. (Neither of which is required, but they're popular options here.) If you keep to one Data instance per DB file (which, yes, many of us are using, including me) then you can still have a unique client object by using the connection factory pattern. Searching on "connection factory" or "connectionfactory" should yeild more hits than you can shake a stick at - restricting it to the last 30 days makes it manageable. (Though you'll probably miss some good older discussions that way.)
    [ August 11, 2003: Message edited by: Jim Yingst ]
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12007
    215
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi David,
    Assuming you don't have the cookies ....
    In the Fly By Night Assignment, we had a similar problem. Only one instance of Data class, and no cookies.
    Max read the FBNS instructions as implying that the Data class needs to be aware of who owns the lock, and the Data class needs to enforce that only the owner of the lock may modify a given record.
    I read the FBNS instructions as implying that the connection could track which locks it owned, moving the issue of ownership away from Data class. I passed with this design (although I lost 4 marks in Server, so I cannot guarantee that I was right).
    Perhaps you could look at your instructions to see whether you think that ownership of locks needs to be enforced within the Data class (I suspect from your quotation that it might).
    * * * * *
    Soemthing else to think about then - do you need to have your meta data parsing / file channel code inside the Data class? If you move that functionality to a helper class that Data calls, then you get the best of both worlds - a single instance of a class to do the disk access, and multiple copies of Data which can be used in tracking locks. Data becomes a facade to your low level database routines
    Regards, Andrew
     
    David Lindquist
    Greenhorn
    Posts: 6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Jim and Andrew. You have given me some good ideas to think about.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic