• 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:

URLyBird question

 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ,


It's locking again .

I have the following interface :




i've implemented this interface and added two additional methods :




Now, when I'm writing the code, i'm reallizing that i have to alter both the public void delete(int recNo) method and the <v>public void update(int recNo,String[] data), to add an client identifier. I need a client identifier argument to identify whether a special someone does/doesn't hold the lock.
Of course, since i added another IF to my example, i could overload these two methods , to take the clientId as a parameter.


The question is :
How have you guys done this?
What have you done with the lock(int recNo) methods provided by Sun. I myself have implemented them to work using the Thread as an identifier, but annotated them with @Deprecated.



Really looking for suggestions,
Thanks,

Victor
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Victor,

I kept the interface from sun as-is, just extended it with 1 extra method

which has to be called before each lock, update, delete and unlock method call as an atomic operation. The purpose is easy: just set the id of the client application so locking logic can be applied.

So to lock a record you have something like


Kind regards,
Roel
 
Victor Bucutea
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thaks for the reply , Roel.


Your mechanism really works ( You might know that already ) ! But I spent a hell of a lot of time on getting my class to be as Thread safe and as fast as possible ( which are two things that don't go well together), so I'm not going to choose this approach, because it involves synchronizing on the whole data object.
The more I think about it, the more I realise that I'm trying to do more than Sun asks. Basically my interface just locks one record. It does not care if multiple clients call updates or deletes on that record. Why should I care?. The data class is supposed to handle concurrent updates on the same record. This locking mechanism just saves us from a bunch of nasty mean Threads which will want to update other records while we're working.



Given what Sun asks :


Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above .


I think the best solution is to go with the simple plain old lock-one-record-no-matter-what-client approach.What do you say 'bout it?

Thanks for getting my ideas straight .





Victor

 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just one thing that you have to keep in mind Victor, let's say that I have an application that expects the interface that was provided by Sun. If I use your implementation of the Data class, is it going to work properly?
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Victor,

If I understand you correctly: client 1 locks record 1, then client 2 updates record 1 and finally client 3 unlocks record 1. That's a scenario that would be possible with your approach?
I don't think that's the way your Data class should work. Why would you then have to call lock and unlock before/after updating a record if you don't care about it.

Why you need a lock-method, you can read here in the scjd-faq

Kind regards,
Roel
 
Victor Bucutea
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Roel,

Glad you mentioned it, because i didn't think about this case.


client 1 locks record 1, then client 2 updates record 1 and finally client 3 unlocks record 1



The problem is like this : We have 3 clients.
Client 1 is locking record 1, Client 2 tries to lock record 1, but is waiting, Client 3 tries to lock record 1 but is also waiting.
Client 1 finishes it's work, Client 2 will add the lock to record 1 and so on...
This would be the normal behavior.


It might happen that after Client 2 obtains the lock, another Thread, just finishing it's job to remove the lock. Thus leaving Client 2 unable to update because a lock on that record does not exist.

The way I see it, a fix would be to increment a counter each time a record is locked, and decrement it each time a record is unlocked. What do you say?


Victor

 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Victor,

What I say is easy: a record locked by client X can only be updated/deleted by client X and can afterwards only be unlocked by client X. If any client tries to update, delete or unlock a record without owning the lock on that record, will result in an (IllegalState)Exception being thrown.

No fuzz with incrementing and decrementing some counter.

Kind regards,
Roel
 
Victor Bucutea
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agree with you on that one , but that would imply


Either implementing sun's interface and adding an additional layer ( this was actually the first solution i implemented ), but frankly I don't know what to write in the lock() and unlock() method implementations in the interface provided by Sun. Or implementing the solution you proposed,which is nevertheless my second choice to the one I'm trying right now.



Victor

 
Here. Have a potato. I grew it in my armpit. And from my other armpit, this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic