• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Locking vs. Logical Locking

 
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What exactly is the difference between what I have read from posts as locking and logical locking? Here is my locking situation: I have a Hashmap that keeps track of the lock cookies and who has a lock cookie on a record. I also synchronized my methods update, lock, unlock, and delete. Am I going in the right direction or am I missing something big? I want to avoid failing at any cost, and especially the dredded 44/80, though sometimes I wonder if it is inevitable.
[ January 06, 2005: Message edited by: Daniel Simpson ]
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Daniel,

In this forum we often refer to the usage of synchronization as physical locking, and the usage of cookies to "own" a lock as logical locking. That is, if a thread is inside a synchronized block, then the JVM enforces a rule that no other thread can own the mutex - the other threads are physically locked out. Whereas the usage of cookies is something that you must implement yourself, and you have to decide how to implement the business rules for it - this is just a logical exercise on your part.

The names we are using in this forum are not necessarily the best, but they have persisted over the years.

Am I going in the right direction or am I missing something big? I want to avoid failing at any cost, and especially the dredded 44/80, though sometimes I wonder if it is inevitable.



So far so good. You might want to think about whether you want to synchronize at the method level, or whether having synchronizing blocks within the methods would give you greater concurrency, but that is your decision.

There is nothing in your post which would indicate whether you are tending towards a 44/80 score. You might want to look at the post "The Mysterious 44/80 Locking score". You might also like to look for some of Anton's posts on the subject .

Regards, Andrew
 
Daniel Simpson
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Andrew. I really appreciate it!
I've been redoing some of my Data class and making it now into a facade. Now all I have left to do is the networking portion of the assignment. I gotta figure out how I'm doing to do this.
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Daniel!!

Good to see you are completing your assignment. I wish you best in passing it. I think that if you make sure that not only your lock/unlock works, but also that your create method is implemented so it does not cause any problems. Consider the following situations:

  • two or more threads call create method simultaneously.
  • a thread is running the create method while another is hypothetically running lock-delete-update-unlock, and the create method cuts in between delete and update.


  • This should force one to think about various issues with their locking implementation. The create method should not reuse deleted records while they are still locked, for instance.

    This raises another possibility. What happens if two create methods determine the same record number to be reusable while it is locked? I would suggest avoiding this situation completely because then you will have to write into your create method some pretty complex logic to avoid different threads overwriting each other with the create methods. I would suggest the create method should find a non-locked deleted record and overwrite it.

    Also, test your lock method. Does it always protect your code from mistakenly operating on non-existing records? Could there be a situation when it passes control to the next method in your locking chain when it should not?
    [ January 08, 2005: Message edited by: Anton Golovin ]
     
    Daniel Simpson
    Ranch Hand
    Posts: 181
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Anton Golovin:
    Hi, Daniel!!

    Good to see you are completing your assignment. I wish you best in passing it. I think that if you make sure that not only your lock/unlock works, but also that your create method is implemented so it does not cause any problems. Consider the following situations:

  • two or more threads call create method simultaneously.
  • a thread is running the create method while another is hypothetically running lock-delete-update-unlock, and the create method cuts in between delete and update.


  • This should force one to think about various issues with their locking implementation. The create method should not reuse deleted records while they are still locked, for instance.

    This raises another possibility. What happens if two create methods determine the same record number to be reusable while it is locked? I would suggest avoiding this situation completely because then you will have to write into your create method some pretty complex logic to avoid different threads overwriting each other with the create methods. I would suggest the create method should find a non-locked deleted record and overwrite it.

    Also, test your lock method. Does it always protect your code from mistakenly operating on non-existing records? Could there be a situation when it passes control to the next method in your locking chain when it should not?

    [ January 08, 2005: Message edited by: Anton Golovin ]

    Thanks for the reply, Anton. In my delete method, it actually calls unlock before deleting the record. I questioned whether a scenario could happen where I run delete, and then delete calls unlock before deleting the record, and then a thread locks that record which is about to be deleted. However, it can't happen because all three methods are fully synchronized. What do you think?
    [ January 09, 2005: Message edited by: Daniel Simpson ]
     
    Ranch Hand
    Posts: 55
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi guys, I think of the reasons people get hit by the 44/80 bug is because they do not take orphan locks (i.e lost clients) into consideration. I am going to use java.server.rmi.unreferenced to detect any lost clients. Thanks AndrewM for your help on this.

    If we use unferenece, how do I detect a clientID? If each client gets its own Remote instance using a Connection Factory when doing a remote lookup, how do I identify that client. For example, my client does remote lookup for the Controller class (I am using a MVC pattern), do I do this during a remote lookup:

    new Thread(new Controller())--- This thread identifies this client. I can then do this:

    Thread.currentThread()-----> will identify the thread that is associated with this client. So when this client dies, its thread dies, unrefenced is invoked and I releas orphan locks. I am not sure how to associate a Thread to a recNo yet.

    Correct me guys if I am way off in my analsis.

    Anton, there is no locking in the create() so how does your solution work. My solution is as follows for the create():

    1. Cache deleted recNos.
    2. Use these recNos for a new record
    3. Write to the database overwriting the delete record, i.e use the same storage space
    4. Update the LIVE cache with the new record
    5. Note the create() is sychronized

    No records are ever locked using the create(), there is no need to.


    Thanks guys
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi GD,

    If we use unferenece, how do I detect a clientID? If each client gets its own Remote instance using a Connection Factory when doing a remote lookup, how do I identify that client.



    If each client has it's own Remote instance, then you can use the instance of the Remote class as the identifier.

    Regards, Andrew
     
    What are you doing? You are supposed to be reading this tiny ad!
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic