This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes cann someone validate my locking approach? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "cann someone validate my locking approach?" Watch "cann someone validate my locking approach?" New topic
Author

cann someone validate my locking approach?

joel smither
Ranch Hand

Joined: Jan 01, 2005
Posts: 31
I'm doing the UrlyBird project. Locking is an issue when the client runs in standalone mode (no networking). Locking IS an issue when I spin up multiple clients to access a single remote database file.

I'm using RMI for the networking piece. When I spin up my server, I register a remote service object in the registry which has a Data object which opens the database file and implements the methods readRecord, deleteRecord, createRecord, etc. As a result, when each client spins up, then will get a unique proxy instance that contains the remote service object registered by the server.

Since almost all of the methods in my Data class manipulate the file position indicator, I have synchronized all the methods in the class. Why? I need to ensure mutual exclusive access to the file.

I have two questions?
(1) Is this approach acceptable?
(2) Doesn't this approach ensure that multiple threads can't update the same record? I keep reading about people implementing a lock manager, but why is that needed in this approach?
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by joel smither:
(1) Is this approach acceptable?


It sounds acceptable, since it meets the musts as described in the instructions.

(2) Doesn't this approach ensure that multiple threads can't update the same record? I keep reading about people implementing a lock manager, but why is that needed in this approach?


Preventing that multiple clients update the same record simultaneously will prevent data corruption, but is not sufficient to prevent that two clients will book the same record.

For that you will need a lock manager. In order to ensure that a record is not already booked, a client must read the record. Then it will have to write its customer ID to the record. But in the meantime no other clients must be able change the record.

For example:

- client A reads record X and determines that it is currently not booked
- client B reads record X and determines that it is currently not booked
- client A writes its customer ID to record X
- client B writes its customer ID to record X

Now client A and B have both booked the record and A's booking has been lost. We don't want this and that's why locking is required. The scenario with locking would be something like:

- client A locks recrd X
- client B attemps to lock record X and is put in wait until A releases the lock
- client A reads record X and determines that it is currently not booked
- client A writes its customer ID to record X
- client A releases the lock
- client B now obtains the lock
- client B reads record X and determines that it is already booked -> abort

Frans.


SCJP 1.4, SCJD
Paul Truckle
Greenhorn

Joined: Feb 22, 2005
Posts: 24
Hello All....I'm looking at this issue myself at the moment. There's a few points in my mind here, and I'm not saying which is right or wrong, but :-

1. If you've synchronized all the methods in your data class, doesn't this mean that effectively you can only have one thread accessing the "Data" object/instance at anyone time ? Wouldn't this prevent two records being booked at the same time anyway ? If you update method included checking the record has not been already booked (read it first) and updating it all in one synchronized method, this
would stop multiple updates happening ? Two threads can't enter the same synchronized method at the same time right ?

2. The downside to the above is that if you synchronize every method, then concurrent file access is not possible. However my
assignment (B&S) states that you can assume that only one program is accessing the database at any one time. If you wanted
concurrent file access then you can't sync all methods and you'd have to consider the file pointer as one instance on it's own would be
all over the place with multiple concurrent access.


Frans, be interested in your comments on the above.
Paul Truckle
Greenhorn

Joined: Feb 22, 2005
Posts: 24
To add to the above, I think some of this raises the decision of client side / server side locking. At this point in time I intented to do expose the locking (lock/unlock) to the client, as the spec suggests so. Also because one of the business requirements is to lock, read, check owner has not been updated, update and unlock. You can't put this in the server side update as it includes a business specifc rule for checking the owner has not been updated. If this is the case, does this mean that the update (server side) should have nothing in terms of lock logic (as it's done from client) side ? Also, when coding the delete method I imagined that this would include lock specific calls within it.

The methods within the data class (or remote data if adapted) would be synchronized to avoid problems with the file pointer being corrupted. Has anyone ever used maybe 2 or 3 file pointers to be used by particular methods...allowing more concurrent access. Although the spec says to assume one program accessing the database at any one point in time.

Comments appreciated please.

Paul.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Paul,

I did indeed implement it as you describe: (un)locking is only initiated client-side. No implicit locking in the (server-side) update or delete methods, because this would taint the data class with business logic.

I think this must be, even if one is making a thin-client design: for a three-tier design (data, business, UI), the functionality of the tiers is the same for thin and fat clients. Only the choice if the business tier is server-side or client-side is different.*

I even allowed each thread to have its own file pointer, as long as they were addressing different records. But if I were to do it all over again, I would probably drop this feature in favour of a simpler design.

Frans.

* However, in a thin-client design, one can perform the actions required for booking a record (read+update) in a synchronized block in the business tier, assuring atomic behavior. Then lock and unlock are not required anymore; this is my main (and only )argument why I think Sun wants us to make fat client designs.
[ February 26, 2005: Message edited by: Frans Janssen ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Paul

If you've synchronized all the methods in your data class, doesn't this mean that effectively you can only have one thread accessing the "Data" object/instance at anyone time ?


Correct. However this will lower concurrent access to the Data class - this might cause you to loose some points in general considerations.

Wouldn't this prevent two records being booked at the same time anyway ?


It will stop two records from being booked at the same time, but it will not stop one booking overwriting an earlier booking.

If you update method included checking the record has not been already booked (read it first) and updating it all in one synchronized method, this would stop multiple updates happening ?


Correct, but then your update method will have to be server side as well, further reducing concurrent access.

The downside to the above is that if you synchronize every method, then concurrent file access is not possible. However my assignment (B&S) states that you can assume that only one program is accessing the database at any one time.


You can assume that only one program is accessing the database at any one time. That is: either one standalone client will be accessing the database or one server will be accessing the database at any given time.

However the instructions do not imply that you cannot have more than one networked client accessing the server application at any given time.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Paul Truckle
Greenhorn

Joined: Feb 22, 2005
Posts: 24
Hi Andrew. Many thanks for taking the time to answer each invidual question. Your answers have been most helpful.

Thanks again, Paul.
Paul Truckle
Greenhorn

Joined: Feb 22, 2005
Posts: 24
Hi Andrew/Frans....I take your point about concurrent access....it has cross my mind and I've not fully commited to a paritcular design at the moment. If that concurrent access was to be opened up allowing more threads to use the class this would probably necesitate a file pointer per thread I would have thought ? At the moment I have one filepointer that is opened from the start. I wouldn't have though it's a good idea to open and close the file pointer for each method update called (create/update/delete etc.). I can only conclude that if more concurrency is offered, then a file pointer per server thread generated by rmi is required. Anyone implemented this ?

Thanks, Paul.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by Paul Truckle:
I wouldn't have though it's a good idea to open and close the file pointer for each method update called (create/update/delete etc.). I can only conclude that if more concurrency is offered, then a file pointer per server thread generated by rmi is required. Anyone implemented this ?


Hi Paul,

I did exactly that: create a new file pointer for every access. I fear I have to concur that it wasn't the best design imagenable (but I was too lazy to change it I think I got away with it ).

In my final design I did have a Data instance for every connected client, so I guess the optimal solution would have been to have one file pointer per Data object (assuming that one client will never access this object concurrently, e.g. from different threads).

Frans.
joe lin
Greenhorn

Joined: Dec 07, 2004
Posts: 28
hi all,
I notice that there is a FileChannel clss in the jdk api.
and this class's javadoc comments:
Bytes may be read or written at an absolute position in a file in a way that does not affect the channel's current position.
does it mean we can do some concurrent access to a file using the file's
fileChannel without worrying about the file's file pointer?
i mean,if all the accesser use the file's fileChannel to access the file,
they will have the file's file pointer themselves?
hope your reply.


Looking for better solution...<br />SCJP1.4
zf sam
Greenhorn

Joined: Feb 16, 2005
Posts: 1
Hi, Paul
I wouldn't have though it's a good idea to open and close the file pointer for each method update called (create/update/delete etc.). I can only conclude that if more concurrency is offered, then a file pointer per server thread generated by rmi is required. Anyone implemented this ?

yes, I think it is a heavy operation for OS to open and close one file pointer, it is not a good idea to maintain several file pointer frequently.
Maybe use only one fp and chg its position every client access, right?

regards, sam
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: cann someone validate my locking approach?
 
Similar Threads
Doubts reagarding database operations for Bodgitt and Scarper
Data Server Design
passed SCJD with 360/400
NX: Client side lock vs Server side lock
URLyBird 1.1.3 design questions