(URLYBird 1.3.3] yet another guy disturbed with LOCK feature

[guillaume ame]

Hello,

As many developpers working on SJDC, I'm figthing with locks

To prepare myself for this part I have read a lot about thread, synchronized blocks and new Lock interface in Java 5.
I have as well read a lot from this forum, especially:


Topic: Clarification on Record Lock without Cookie
Topic: locking without cookies
Topic: NX: lock/unlock - how to identify clients without lock cookie


But I'm not enough confident with my code and the moreI read about that, the more I get confused...

So at the moment I have the following code (given in ugly pseudo-code, I hope I don't break forum rules). Please have a look and tell me what you think of it.

My Data class is using a LockManager, which is an Object composed of a synchronized Set (with help of java5 ReadWriteLock).
- When a record is lock, its recNo is put on the Set.
- When a record is unLock, its recNo is removed from the Set.

Data class:
public synchronized void lock (int recNo) {
wait while lock is set for recNo;
add recNo into lockManager;
}

public synchronized void unlock(int i) {
remove recNo from lockManager;
signal to waiting thread that lock has been released;
}

lock/unlock are call from Data class when read() and from client when update()/delete().

The whole Data instance is lock when create a new record.

Points that confusing me are:
- is that locking scheme is correct ?
- how to handle special case like a client disconnect while updating...

How to insure the lock/unlock scheme ?

<edit>
after reading again post about locking I figure some problems in my implementation.
I understood I have to:
- always call lock/unlock from client
- use one Data instance per connection with help of a Factory
- use a Map instead of a Set to store locked recNo
- use a mechanism to unlock a deleted record
- handle dead or very slow connection is pretty hard

Now I'm still confused :

- isn't it dangeous to delegate locking call to client ? What will happen if
a client does direct call to update/delete/read ???

- why should I identify who locks the record (with a cookie or with factored Data instance) ???

- In an older thread I have read about someone who got 100% on lock while having change signature of lock from lock(int recNo) into lock(int recNo, int cookie). Isn't this too hazardous ???

- what if I don't implement the last point (slow or dead connection) ?

</edit>

Thanks you for all comments and advices you may post
[ September 28, 2005: Message edited by: guillaume ame ]

[Oricio Ocle]

Hello Guillaume,
oouuu how many lines....
well using a LogManager:
I think is a good decision. Delegating is good pattern and makes your code more readable. But...

Data class:
public synchronized void lock (int recNo) {
wait while lock is set for recNo;
add recNo into lockManager;
}

public synchronized void unlock(int i) {
remove recNo from lockManager;
signal to waiting thread that lock has been released;
}

do you think this is good enough? What differences your lockManager from an usual collection object?

Other issues, what happens with attempts of locking different records?

lock/unlock are call from Data class when read() and from client when update()/delete().

Are you sure you are understanding the aim of the locking schema?
data corruption? yes, but what kind? Look there, there are some intesesting threads about that.

- isn't it dangeous to delegate locking call to client ?

there are some interesting threads about that, are the cookies necessary?

Andrew's extense thread

use a Map instead of a Set to store locked recNo

What information do you need to store in order to perform locking/unlocking?
And more, what implementation of those interfaces to choose?
Which constructor?

I think these are some good points to think about.

Hope being helpful
Regards

[guillaume ame]

hi again and thanx for your quick response

oouuu how many lines...

oups... yes it's a bit verbose... but this reflect my confused mind about lock

do you think this is good enough?

i'm not sure at all !

What differences your lockManager from an usual collection object?

well, it's suppose to be synchronized with a read/write lock. So many thread can read the collection at the same time and only one can update it. When reading, writing is blocked. When writing, other writing and reading are blocked.

Other issues, what happens with attempts of locking different records ?

it's supposed to lock only access to target record.

Are you sure you are understanding the aim of the locking schema?

I understood that only one client can update/delete a given record at the same time. When a client wish to update, record is lock until update is complete...
But I'm confused with some situation:
- is reading a record should be block once someone is updating it (i guess yes)
- is create function should lock the whole data object to avoid creating object with the same ID ?

What information do you need to store in order to perform locking/unlocking?
And more, what implementation of those interfaces to choose?
Which constructor?

Well I figured once that I only need the recNo. But after reading a lot in this forum, I got confused with the need of client cookie.
Now I figure that we need client info in order to avoid client to unlock a lock it doesn't got before... This could happen when client is in charge of locking/unlocking... Am I correct ?



After having playing a few with thread and locks in a side sandbox project, I'm still in trouble when I want to check everything is ok with locks.
How being sure that thread are well synchronized ?

Thx again for reading my verbose brain dump !

[Oricio Ocle]

Hello again,
reading again your post i've just noticed that your lock method doesnt return any value... maybe an typing error. Let's supose it's like ours..

About the use of lockManager:

delegate business tell us:

  
public long lock(long recNo){
   return lockManager.lock(reNo);
}

ie, data object doesnt know how to deal with locking issues and delegates to her friend lockManager. This is what i'm speaking about,in your implementation lockManager is an standard Set/Map

In those threads i told you, it's explained that there are two kind of data corruption:
Phisical corruption, produced by concurrent io operations in the db file, suposing you have only one instance of a raf...
And business corruption, due to concurrent users of the application. Here is where the locking schema has sense. Search the forum and you'll find very good post about that. Maybe Andrew knows which thread i'm talking about...

Regards,

[Oricio Ocle]

Another example of business delegate: MY BOSS

doen't know how to deal ... and delegates

Regards