• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Database Wizardry (or lack thereof)

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Title: NX: Database Wizardy (or lack thereof)
Hi,
Here is some terminology which has, perhaps in passing, been mentioned in some
posts recently:
* One client can request to lock more than one record at one time.
* Automatic unlocking of a lock (or locks) owned by a crashed client.
* Deadlock detection.
* Deadlock detection (of crossed lock claims, crashed clients, or both)
such as in
Topic: NX: Why do you all make LockManagers?
http://www.coderanch.com/t/185355/java-developer-SCJD/certification/NX-Why-do-you-all
Topic: Lock question!
http://www.coderanch.com/t/185337/java-developer-SCJD/certification/Lock
I appreciate seeing issues that more advanced database-minded people--such as
Phil and others--work with and implement.

My question is simply a check to reinforce that my simple database design is
sufficient.
Here it is:
1. One client is only allowed to hold one record lock at any given time. If
the client attempts to lock an additional record while already holding a record
lock, a SecurityException is raised. In this manner, deadlock is impossible.
2. Concerning crashed clients: at this time there is no code implemented to
unlock a record that was locked by a client that subsequently crashed. And,
given that I want to continue to move forward with completing this exam "in a
timely manner", it is highly possible that I will not implement this feature.

So, is my simple, straightforward locking scheme acceptable to receive full
points?
Thanks,
Javini Javono
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
Originally posted by Javini Javono:
So, is my simple, straightforward locking scheme acceptable to receive full
points?

I think so. Of course, you'll want to mention these points in the design decisions document.
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Javini Javono:

* One client can request to lock more than one record at one time.
* Automatic unlocking of a lock (or locks) owned by a crashed client.
* Deadlock detection.
* Deadlock detection (of crossed lock claims, crashed clients, or both)
1. One client is only allowed to hold one record lock at any given time. If the client attempts to lock an additional record while already holding a record lock, a SecurityException is raised. In this manner, deadlock is impossible.
2. Concerning crashed clients: at this time there is no code implemented to unlock a record that was locked by a client that subsequently crashed. And, given that I want to continue to move forward with completing this exam "in a timely manner", it is highly possible that I will not implement this feature.

Javini,
I am new to SCJD and still working on my locking design. I am thinking of not implementing both the features in my design.
Feature 1: Deadlocks are prevented, but wouldn't this restrict future enhancements of the application? Say, if there is a new use case in the future that would require the locking of record A and acquire an additional lock on record B by the same client?......You are preventing deadlocks and also such future enhancements by enforcing this restriction currently.
In my design, I am assuming that deadlocks wouldn't occur as there is no business case which demands acquiring multiple record locks in the assignment. If such a business case arises, a new deadlock prevention design anyway needs to be introduced.
Feature 2: This is way beyond my head.
 
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 Vish & Javini,
Javini - I agree with George's answer.
Vish - yes, there may be future requirements that need either item 1 or item 2 in Javini's list. However there are several problems with that way of thinking:
  • We don't know what the future requirements will be.
    You could spend a week gettting these two items 'perfect' and then find that they do not meet the future requirement anyway, which would mean all your hard work would have to be redone.
  • In the real world you would normally have a deadline in getting the product out the door.
    Your manager / customer is unlikely to thank you for delaying the project by a week so that you can fit features that were not required.
  • In the real world, time costs money.
    If you are working on a fixed price contract for someone, then you will be giving away these extra features. If you are working on a "time and materials" based contract then you will be charging the customer for things they haven't asked for.


  • Extreme Programming even has a term for why coding for future requirements should not be done: You Aren't Gonna Need It (YAGNI)
    Now on the other hand - if, as a learning exercise, someone wants to implement deadlock handling code, or implement some method of handling crashed clients, then I (and others) are more than willing to help out. These can be interesting to learn about now, and one of the benefits of this certification is that you can take the time to learn all sorts of new things.
    Regards, Andrew
    [ March 16, 2004: Message edited by: Andrew Monkhouse ]
     
    Philippe Maquet
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Javini,
    2. Concerning crashed clients: at this time there is no code implemented to
    unlock a record that was locked by a client that subsequently crashed. And,
    given that I want to continue to move forward with completing this exam "in a
    timely manner", it is highly possible that I will not implement this feature.

    I think everybody on this forum agrees on the fact that handling crashed clients is not a requirement for this assignment. But of course you can do (even just - as Andrew suggests - for learning purposes).
    1. One client is only allowed to hold one record lock at any given time. If
    the client attempts to lock an additional record while already holding a record
    lock, a SecurityException is raised. In this manner, deadlock is impossible.

    Of course you avoid deadlocks (anyway due to crossed lock claims - not crashed clients), but at the cost of a limitation of the provided DBAccess interface as it's documented. Nowhere you can find that a client should not be allowed to own more than one lock at a time. OK, your business layer doesn't need it, but is it that limitation compatible with the Data layer contract as described? I ask the question because I have no definitive answer on this. But I wouldn't take the risk, personally.
    For two main reasons:
    - your lock() method now throws a SecurityException which was not documented in the provided interface (OK, it's a Runtime one, but other methods declare it explicitely, so...)
    - it's easy to avoid deadlock just by imposing (by contract) that locks must be claimed in an ordered fashion (I know that some people chose that solution which require nothing special as far as your locking implementation is concerned, in comparison with real deadlock detection which is another story and probably overkill, though some people implemented it nevertheless).
    Best regards,
    Phil.
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    Thanks for your responses.
    I had forgotten that if each client wants to simultaneously hold
    several locks, and each lock in this set is requested from lowest
    to highest, that this will prevent dead-lock (I seem to remember
    either thinking about this or writing about it in the past).
    If this is the case, and I'd have to think about it to come to final
    conclusion, it sounds like no added effort to allow the client
    to follow these rules to claim multiple locks.
    However, it does add a security concern, in that the database
    is vulnerable to bad client programming.
    So, I may make this a server preferences item: allow client
    multiple locks following specified convention or no.
    Thanks,
    Javini Javono
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic