Originally posted by Tony Collins:
Sorry for taking up you time Max,
but isn't that scenario only valid if your methods are sync'ed. If your adapter and data class have no synchronized methods and your synchronization is only within the data class on a static member. Then I can't see why multiple instances make a difference.
Tony
Originally posted by Eugene Kononov:
Max: Think of two clients, Andy and Barbara, who are trying to work with records 1 and 2 respectively and concurrently. In the single Data paradigm, Andy has to wait for Barbara to lock, modify, and unlock record 2 before Andy even gets started with record 1.
I am not sure I follow you, Max. In my design, I did use a single instance of Data (per database table). But Andy didn't have to wait for Barbara to unlock record #2 if Andy was interested in record #1.
Originally posted by Tony Collins:
Yeah it made sense I just couldn't understand if I'd made some drastic error with my design.
I sync'd on the cache for all access to the database.
Just been reading your McDonalds example, I noticed it's sometimes a false optimisation to lock objects directly. But I've set my design in stone now.
I do think I should have followed the easy path but in some ways I've learn't a lot more by not keeping it simple.
Cheers for your help much appreciated.
If your ever local let me buy you a few drinks some time.
Cheers
Tony
"I'm not back." - Bill Harding, Twister
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Originally posted by morgan bath:
Ok, I am totally confusedI am so used to using jdbc I never realised the mental yoga going on in the DB ....
But im left with this question: If you are using a single instance DB and you are syncronising all methods OR syncronising on the cache, why do you need lock and unlock anyway?? Surely this approach makes sure only one client is ever attempting to alter data at one time. Locking prevents two or more clients altering the same record right? But in the single instance synced method approach only one thread is ever changing any record. Or am I missing something here.
I read Mr Habibi's book and liked it, but the record locking part leaves me feeling ive missed something huge and important. I feel im going in circles on this one issue.
I though j2se would be easier than j2ee![]()
But im left with this question: If you are using a single instance DB and you are syncronising all methods OR syncronising on the cache, why do you need lock and unlock anyway?? Surely this approach makes sure only one client is ever attempting to alter data at one time. Locking prevents two or more clients altering the same record right? But in the single instance synced method approach only one thread is ever changing any record. Or am I missing something here.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Originally posted by George Marinkovich:
Hi Morgan,
An illustration of why one needs lock and unlock:
Suppose your client has a book method that reads a record and then updates the record. Suppose further that there must be no intervening update on the record in question between the read and the update. How do you make this kind of guarantee without the lock and unlock methods? With locking one can lock the record, read the record, update the record, and unlock the record. Because of locking one knows that no other update occurred between the lock and the unlock. How can this be accomplished without locking?
Hope this helps,
George
[ January 17, 2004: Message edited by: George Marinkovich ]
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
I hadnt intended to lock all records read by one client. I had thought to have the client display multiple rows (All unlocked) and then lock them when and only when they tried to book or unbook the contractor. This would require the book method to check if the record had been booked since the last read and tell the client if this was the case.
How are you doing it? Are you locking all records passed to one client and not allowing any other client to even read that record until the previous client has cleared his lock? What if one client is viewing all the records? Can noone else view them at all? Or do you have active locking where it locks on the JTable row highlighted?
This brings up another question actually. When the client fist executes should the JTable show all the records, or wait until you enter some search criteria?
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Originally posted by George Marinkovich:
I think the JTable should show the client all the records at the beginning. The user can filter the JTable display by entering search criteria as he wishes.
Hope this helps,
George
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
But ive decided even though the assignment insists I implement an interface with lock and unlock as public methods im going to have an adaptor pattern and hide lock and unlock from the client. I prefer a higher level of abstraction between client and server.
Regards, George
SCJP, SCJD, SCWCD, SCBCD
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Peter
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Originally posted by Eugene Kononov:
MB: Seems to me that single or multiple instance it doesnt matter.
If you use a single instance of Data that is shared among the clients, it is enough to have its methods synchronized to ensure that no two threads are writing to the database at the same time. In this implementation, the semaphore would be the data object itself.
If you use multiple instances of Data, one instance per client, it would not be enough to have the methods of Data synchronized, because in this implementation, two different instances of Data can run their methods at the same time, even if these methods are synchronized. To ensure a proper synchronization in this implementation, you would need to synchronize on the object other than Data. That could be a static object that is a member of Data, for example.
Originally posted by Eugene Kononov:
There have, indeed, been lengthy debates in the past discussing which approach makes more sense. Read them, analyze them, and make your decision.
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
I guess I've been abducted by space aliens. So unprofessional. They tried to probe me with this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|