This week's book giveaway is in the Java in General forum.
We're giving away four copies of Java by Comparison (eBook) and have Simon Harrer, Jörg Lenhard, Linus Dietz on-line!
See this thread for details.
Win a copy of Java by Comparison (eBook) this week in the Java in General forum!

Jacek Balcerski

Greenhorn
+ Follow
since Mar 14, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jacek Balcerski

Roel De Nijs wrote:My opinion about this issue is pretty simple and straightforward: a thread can NOT acquire the lock on a record that is already deleted, so a RNFE should be thrown. That's the approach I followed.



Sure, the problem is you have to deal with 2 locks, first is on database io, second is on locks (map/list whatever). During locking you have to lock the locks map BUT you also have to lock database io to check
record validity. You have to have both locks to be sure locking works perfect but this can lead to deadlock -> Am I right ? You could first lock database io then release it then lock locks map but this could lead to data inconsistency.

Roel De Nijs wrote:And if Sun (Oracle) accepts the solution you suggests, I really don't know. And I can't think of any valid explanation in your decisions document, because: how can you lock (update) a record that does not exist anymore


Here it is (no code ofc), and I'm perfectly understand you can not say whether Oracle accepts any of my solutions (points of view).


public void lock(int recNo) throws RecordNotFoundException;
public void unlock(int recNo) throws RecordNotFoundException;
public boolean isLocked(int recNo)

I decided to hide atomic lock and unlock methods from client. Given interface DBMain is implemented in Data class witch has two static members, DataIO and LockManager; so for all instances of DBMain (Data)
those two statics are shared. I use DBMain objects as clients id's (cookies) All methods in DataIO are synchronized. This is quite obvies and popular approach, I think.

1st dilemma concerns RecordNotFoundException, I see two possible solutions for checking record consistency:
a)
first check Record (synchronized on io acces object) throws RNFE
then lock record (synchronized on locks)
But between checking record and locking record this record could be deleted/recreated etc. BUT I SAW this kind of solution to be maximally marked on SCJD witch personally I don't understand

b)
first check Record (not synchronized) throws RNFE
then lock record (synchronized on locks)
then check Record (not synchronized) throws RNFE (before throw exception unlock)

Checking record is not synchronized because it just read the state of record and it should be really fast ,
but I'm not sure making checkRecord non synchronized is perfectly safe. What would you suggest, any other ideas?

2nd dilemma
In my lock and unlock methods I don't check repeated locking (second locking this same record by this same client) Should I bother this kind of situation ?
If so, what approaches would you suggest ( Maybe you can read SUN's (pardon me ORACLE) intentions better than I do)
a) throw some kind of RuntimeException
b) just skip second try, leaving record locked as It was after first locking operation and just log info about second try ?

3rd dilemma
is about public boolean isLocked(int recNo) I don't see necessity to use this method.
a) Do I have to use it in my other methods?
b) Should it be just non synchronized dirty read about lock
c) Should it be synchronized read about lock ?

Jacek Balcerski wrote:BUT I SAW this kind of solution to be maximally marked on SCJD witch personally I don't understand

Roel De Nijs wrote:And where did you see this? Because if it is on this forum, tI have to delete this post, because code of complete locking mechanisms are not allowed.



No, it is not on this forum, it was one of my collogues.

Cheers!

[edit] no need to quote someone else's entire post

Thanks for answering my questions Roel, sorry for delay I was out of computer for last couple of days.
I still thinking about first dilemma. I suggested that check record would not be synchronized on data IO. This however could lead to little problem,
let us consider such a situation:
Thread1 checks record No 1
Thread2 checks record No 1->locks record No 1->check record No 1-> delete record No 1->unlock record No 1
Thread3 checks record No 1->locks record No 1->check record No 1-> modify record No 1->unlock record No 1
Thread1 lock record No 1->check record No 1->modify record No 1-> unlock record No 1
This way at the end of operation we stay with modified record witch is not this one we wanted to modify at the very beginning.

Is this solution really acceptable by SUN ?

The exists at least two bullet proof solutions, I think:
a) synchronize on data io to access locking mechanism (this is 100% sure but slow)
b) synchronize locking and checking record (this requires implementing some sort of dead lock detection)

So what do you think first approach when check record is not synchronized. Is it acceptable (if described in decisions) by SUN
even if it can lead to modifying record modified by some other thread; or maybe I should consider locking whole database io to lock record ?

Thanks again!

P.S. I recreated my first post. I have read FAQ yet
Hi every one
Intro:
I got URLyBird, no cookie, I almost finished whole project but I'm still have sleepless nights because of locking mechanism

public void lock(int recNo) throws RecordNotFoundException;
public void unlock(int recNo) throws RecordNotFoundException;
public boolean isLocked(int recNo)

I decided to hide atomic lock and unlock methods from client. Given interface DBMain is implemented in Data class witch has two static members, DataIO and LockManager; so for all instances of DBMain (Data)
those two statics are shared. I use DBMain objects as clients id's (cookies) All methods in DataIO are synchronized. This is quite obvies and popular approach, I think. My locking mechanism looks like this:

[edit] don't provide code snippets of your actual locking mechanism

1st dilemma concerns RecordNotFoundException, I see two possible solutions for checking record consistency:
a)
[edit] don't provide code snippets of your actual locking mechanism

But between checking record and locking record this record could be deleted/recreated etc. BUT I SAW this kind of solution to be maximally marked on SCJD witch personally I don't understand

b)
[edit] don't provide code snippets of your actual locking mechanism

but I'm not sure making checkRecord non synchronized is perfectly safe. What would you suggest, any other ideas?

2nd dilemma
In my lock and unlock methods I don't check repeated locking (second locking this same record by this same client) Should I bother this kind of situation ?
If so, what approaches would you suggest ( Maybe you can read SUN's (pardon me ORACLE) intentions better than I do)
a) throw some kind of RuntimeException
b) just skip second try, leaving record locked as It was after first locking operation and just log info about second try ?

3rd dilemma
is about public boolean isLocked(int recNo) I don't see necessity to use this method.
a) Do I have to use it in my other methods?
b) Should it be just non synchronized dirty read about lock
c) Should it be synchronized read about lock ?



What do you think of my three little challenges ? Any suggestions would help, sorry for my tongue.
Best regards, Jacek Balcerski
Hi
According t what I have read about MVC patter I see three options to implement assignment:
1) Use famous observer pattern

2) Make POJO controllers. Controller would implement Then I would define method in view In this method for every gui element I need I would call where is my controller. Then in controller in method I would make my choices according to action commands.

3) Make POJO controllers. In controller I would define private classes (each implementing ActionListener or WindowEvent etc) implementing calls to businesses logic . In view I would define getters returning gui elements I'am interested in. In controller I would call those getters. On returned GUI elements I would call passing already defined objects <ActionListener>.

I personally think 3 version is the most clean but I'm not really sure is it acceptable from exterminator point of view. What do you think of that ?
Jacek
a) sorry for my English
b) I'm not strict GUI developer so sorry if you consider my questions silly