File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Which locking mechanism should i use... need comments and urgent Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Which locking mechanism should i use... need comments and urgent" Watch "Which locking mechanism should i use... need comments and urgent" New topic
Author

Which locking mechanism should i use... need comments and urgent

Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
Dear folks:
after reading the relative topics of locking in the forum, i conclude three locking mechanism, and listing it below:

Prerequisite APIs by assignment:


Solution 1: Performs record level lock.
opt1: Only lock the record that needs to be modified or deleted.
advantage: absolutely fill the requirements.
disadvantage: "dirty reading" will occurs.

opt2: Lock the record when reading/modification/deleting
advantage: "dirty reading" won't happen.
disadvantage: very poor efficiency; not 100% fill the requirements.
(Locks a record so that it can only be "updated" or "deleted" ...)


Solution 2: Implements the database level "Readers/Writer Pattern"
advantage: Easy to implement and the efficiency is not bad.
disadvantage: Not fill the APIs requirements.


Solution 3: Implements the record level "Readers/Writer Pattern"
advantage: Best efficiency.
disadvantage: Not fill the APIs requirements and needs hard coding.


My question is:
1. Which solution you choice?
2. Any people use solution 2 or 3 and pass the exam? if yes, how many score
in the locking section they got?

Needs predecessor's comments, any comments are welcome.

Best Regards.
[ July 14, 2004: Message edited by: Ching-Tien Chang ]
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Ching-Tien,

The cookie locking mechanism should not affect the reading a record (although reading/updating operations should be synchronized to ensure their integrity) - such exclusivity is not a requirement.

By dirty reads, if you mean that the client may have a copy of a record which is out of date (i.e. has been changed since it was read), this is certainly an issue and should be documented. When updating, you would need to check that your copy of the record to be updated has not changed and take appropriate action if it has.

Regards,

Jon
[ July 14, 2004: Message edited by: Jon Entwistle ]

SCJD, SCEA
Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
hi Jon:

for solution 1, "dirty reading" i means:


original data(10'th record):
A B C D E

client A:
lock(10);
update("1 2 3 4 5", 10);
|(start update)
| there are one moment, data will be "1 2 3 D E"
|(update finish)
unlock(10)


Since read(recNo) did not perform lock(10) before reading ,so at the moment

Client B:
read(10); -----> and get the 10'th record is "a b c D E"


that is the "dirty reading" i mean.

hopes my explain is clearly
[ July 14, 2004: Message edited by: Ching-Tien Chang ]
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Ching-Tien,

Tell me if I am wrong, but the problem you are describing is when two clients are trying to access the data at the same time, one reading, one updating.

If this is correct then it is a thread issue - methods must use synchronization to ensure that an update is not interupted by any other client reading the data which is part way through being updated.

Hope this helps,

Jon
Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
hi Jon:

yes, you are right, this is about thread issue.

If all data access method use synchronized, there are no "dirty-reading"

occurs. But if we do so, there ary only one client can access the database

file at a moment.

In the SCJD exam, do we need to achieve "simultaneously reading/writing

database" or "just synchronized all method, one client can access the

database file at a moment is okay"?



synchronized all method:



simultaneously reading/writing database






Grateful for your reply.

[ July 14, 2004: Message edited by: Ching-Tien Chang ]
[ July 14, 2004: Message edited by: Ching-Tien Chang ]
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi,

In the SCJD exam, do we need to achieve "simultaneously reading/writing database"


No - there would be no protection against corruption of the database.


or "just synchronized all method, one client can access the
database file at a moment is okay"?


Not necessarily - you only need to synchronize those parts of the code which need the protection of synchronization.

Regards,

Jon
[ July 14, 2004: Message edited by: Jon Entwistle ]
Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
You mean makes the DataAccess class singleton and synchronize all data access method? if do so, there are one client at a moment can "really" access the database file, and when the client is access the database file, there ary no other client can interrupt it, if so, why we needs the APIs
lock(recNo)
unlock(recNo)
isLock(recNo)

could give me a scenario that needs the lock/unlock call?


appreciative,
Ching-Tien Chang
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
You mean makes the DataAccess class singleton


No - what happens if you add extra tables to the database?


synchronize all data access method?


No - just synchronize the code that needs it, wether that be a method or blocks of codes in methods.


why we needs the APIs
lock(recNo)
unlock(recNo)
isLock(recNo)


You are just providing a mechanism for clients to declare that it wants exclusive delete and update rights to this record. It is up to you to code clients to honour this convention. This has no relation to writing thread safe code.

Regards,

Jon
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
I have the same confusion, and though I realise that the reason for sync on data and locking records has different purposes the implementation of these does seem to result under some designs to amount to the same thing.

Compound operations aside (eg lock, read, update, unlock)

for instance if you do lock, read, unlock then the read would be effectively locked anyway since the read has been synchronised. Then not only is that record locked but every record is locked!

I'm not trying to convince you are mistaken, I know there is mental block my end, I still do not fully understand.

See this (presently) small
thread too.


SCJP 1.4, SCJD
Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
Dear Jon:

----------------------------------------------------------
You mean makes the DataAccess class singleton
----------------------------------------------------------
No - what happens if you add extra tables to the database?

Maybe in another words, how many RandomAccessFile object can actually access
database file?
ps. In SCJD exam, database = database file = only one table



--------------------------------------------------------------------------

synchronize all data access method?

--------------------------------------------------------------------------
No - just synchronize the code that needs it, wether that be a method or blocks of codes in methods.


agree with you.


----------------------------------------------------------------------------
why we needs the APIs
lock(recNo)
unlock(recNo)
isLock(recNo)
---------------------------------------------------------------------------
You are just providing a mechanism for clients to declare that it wants exclusive delete and update rights to this record. It is up to you to code clients to honour this convention. This has no relation to writing thread safe code.


if update() is synchronized, ClientA update 1'th record, and at the

same moment ClientB update 1'th record.

either ClientA or ClientB can get "synchronized", if ClientA

get "synchronized", ClientB are blocked in synchronized pool until

ClientA release the "synchronized". so there is no need to call

lock() before update(), because this is all done implicitly.


thanks sincerely,
Ching-Tien Chang

[ July 14, 2004: Message edited by: Ching-Tien Chang ]
[ July 14, 2004: Message edited by: Ching-Tien Chang ]
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Mike,


for instance if you do lock, read, unlock then the read would be effectively locked anyway since the read has been synchronised. Then not only is that record locked but every record is locked!


The difference is that synchronization locks records for a couple of clock ticks to prevent a shared variable from being changed by two threads at the same time - atomicity of these operations must be maintained to prevent data corruption.

Our lock/unlock methods give the client the power to mark a record as off limits to other clients for deletes and updates during an unconstrained period of time - e.g. the client can lock record and keep it locked while the user updates the record, user goes to pub, user buys some fags and a beer, watches the footy, comes home, reads the records again then deletes it before finally unlocking it. If this is the business logic that needs to be implemented these methods give you the power to do it!

Hope this makes it a bit clearer,

Regards,

Jon
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi,


Maybe in another words, how many RandomAccessFile object can actually access
database file?
ps. In SCJD exam, database = database file = only one table


The specification states that you have to code to facilitate chages in the design - it is not too much to expect more than one table in a database

The simpleton pattern is restrictive - you are limiting youself to one file and one database. THere are better ways around this problem, do a search of this forum for simpleton and you will see all of the arguments.

Regards,

Jon
Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
what you think mike,

i want to listen your opinion





Ching-Tien Chang
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Jon,

My confusion is entirely performance related, I am happy with the reasons for lock/unlock.

I just want to be sure that essentially, say with an uncached system and where the locks are just visible server-side (my likely approach).

that:

DB.lock()
DB.read()
DB.unlock()

will take approx. the same time as just:

synchronized String[] myRafImplementation.readRecord(recNo);

therefore under this design there is no advantage of locking a single record, you might just as well lock the whole database.

I will restate, 'under this design' and I realise that a business method such as book() will always reap rewards from a lock at record level.

Think of this line of query as an assert statement in my analysis process

Thankyou for your time!
[ July 14, 2004: Message edited by: mike acre ]
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Mike,

My confusion is entirely performance related, I am happy with the reasons for lock/unlock


Sun explicitly tells us that performance is not an issue - don't take it into account in your design (within reason!).



Admitedly it is of little use to this scenario, but what about future clients? Keeping cookie locking server side in a proxy/adapter makes implementation easier, but you are not letting future clients have the benefit of this locking mechanism.

Regards,

Jon
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197

Sun explicitly tells us that performance is not an issue - don't take it into account in your design (within reason!).


Yes. My query is just to get matters straight in my head.
If I was mistaken here it may throw a lot of other details based on it out the window.
So you are agreeing with me then.


Admitedly it is of little use to this scenario, but what about future clients? Keeping cookie locking server side in a proxy/adapter makes implementation easier, but you are not letting future clients have the benefit of this locking mechanism.


Well quite, and there are alot of ifs and butw when we decide not to just answer the assignement.
I think 3 tier design is the usual approach.
Perhaps I should do both, ie adapter serverside and reveal the locking.
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Mike,

OK looking at your code:


DB.lock()
DB.read()
DB.unlock()


Why would you want to lock a record just to read it? You lock it to allow you and only you to delete and update or delete the the record. Others can still read it - there is no danger from dirty reads if synchronization has been applied correctly.



No matter what you do, your read must be synchronized. As I say, locking a record does not prevent clients from reading what otherwise could be a record half way through an update.

Regards

Jon
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
In that case, and I see what you are saying, we need input from Max
In his book he has this in his adapter class



reserve/release is synonymous with lock/unlock

db.getDVD is a call to a synchronized file access that reads a file which is the record. (1 file per record).

Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Mike,



As far as I remember, in the context of Max's book getDVD changes the state of the database. i.e. it is an update not a read and so needs to be locked as specified in the requirements.

Regards,

Jon
[ July 14, 2004: Message edited by: Jon Entwistle ]
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Hi Jon,



As far as I remember, in the context of Max's book getDVD changes the state of the database. i.e. it is an update not a read and so needs to be locked as specified in the requirements.



The code that is executed is this:



No attributes are modified, it simply instantiates a DVD via an OIS and returns it. It does not put this object in any kind of cache. I can't see that is anything other than analogous to RAF.read(recNo)
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi Mike,

The only reason that we need to call lock/unlock is for the business rules imposed on us by the spec. - it has been a while since I have looked at Max's code but if his spec requires him to lock before the getDVD operation then that is what his implementation must provide.

Luckily we aren't implenting the spec im Max's book .

Just stick to the spec provided (lock before all deletes and updates then unlock) and you will be fine.

Regards,

Jon
[ July 14, 2004: Message edited by: Jon Entwistle ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11424
    
  85

Hi Mike,

Originally posted by mike acre:
My confusion is entirely performance related, I am happy with the reasons for lock/unlock.

I just want to be sure that essentially, say with an uncached system and where the locks are just visible server-side (my likely approach).

that:

DB.lock()
DB.read()
DB.unlock()

will take approx. the same time as just:

synchronized String[] myRafImplementation.readRecord(recNo);


The calls to lock() and unlock() would presumably require non zero time to perform, so the first option would take slightly longer.

However this is a trivial example, and I noted that you went on to say that:

Originally posted by mike acre:
I realise that a business method such as book() will always reap rewards from a lock at record level.


And that is where the record level locking will give you improvements in performance, especially as your business logic gets more complex and/or you choose to expose your locking methods to your clients.

The book method requires several logical steps to complete, most of which do not need to be within a synchronized block if you have a record lock.

In this case you will potentially get better performance by using logical record locking.

Regards, Andrew

BTW - does this answer your issues in this thread?


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
BTW - does this answer your issues in this thread?


Yes thanks to all.

I am now pretty happy I understand the issues serverside, RMI withstanding

I can now get on and build it.

Then there will be RMI to learn...

At least my Swing is swingin' but only 10% of the marks :roll:

I'm sure there is a secret competition to try and validly use all the smileys
Ching-Tien Chang
Greenhorn

Joined: May 31, 2004
Posts: 16
Thanks for Jon, Mike and Andrew,

I'm glad for understanding the lock issue that specified by the exam.

Sincerely,
Ching-Tien Chang
 
jQuery in Action, 2nd edition
 
subject: Which locking mechanism should i use... need comments and urgent