• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

NX:Locking - one data instance or multiple

 
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After reading over a dozen posts I am still utterly confused why it
is not easier to have one instance of Data rather than multiple
instances of Data. Is it a major performance hit?
It seems with having one instance of data locking is so so much easier.
You simply sychronize on your methods in data and provide lock/wait and unlock methods. Very similar to Max's book.
Is this true? Can someone give a good explanation. thanks
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bill,
both work, but most people here have enough invested in the project that they can't resist the urge to make it shine. It's become a labour of love, and people want elegent solutions.I understand this, so I'm wiling to help them achieve that. OTOH, most people just want to get the test passed. I understand that too, so I wrote the book to use the simpler design
M
[ September 15, 2003: Message edited by: Max Habibi ]
 
Bill Robertson
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But do you feel the simpler design will get the passing grade.
I take simplicity over everything!
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh absolutely. I've had many, many people, including many private students, get perfect score on the SCJD with it. If I'm not mistaken, even Andrew used it.
M
 
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Other than being able to keep track of your own locks, how does multiple instances of Data help you.
Max's book states that it is more efficient for the client to have an instance of data each. Anyone know why it is more efficient ?
Tony
 
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bill,
I can't say that what is better (simple design or better one, but more complicated), since I didn't pass the exam yet, but I beleive your ability to make all simple is the most important criteria to to grade the assignement.
I finished developing my assignement in 1 month. I traing to make it simpler already more than 2 months...
Best,
Vlad
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tony,
It's more efficient for the clients, because they don't have to share instances of Data. However, it's less efficient for the server, because it has to provide multiple instances. It's all a matter of prespective. I probably should have been more clear about that.
M
[ September 18, 2003: Message edited by: Max Habibi ]
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I supose it's only more efficient if the methods are synchronized. If there not and there's fine grain synchronized a single instance should be just as efficient as multiple instances, the bootleneck being the actual data structure underneath. Or am I missing something
Tony
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure I'm following you with the synchronization comment.
Maybe this will help. If you have multiple instances of Data, then two client can concurrently read, search, etc. The only time they will be bottle necked is when they are locking and/or updating the DB file.

OTOH, if you have single instances of Data, when all clients will have to work single file whenever they want to do [i]anything[i] with Data.
Both approaches have their good points and bad, of course. The first requires more processing on the Server, and is more complex to code. The latter is less efficient, and less client friendly. So long and you've explored the drawbacks of each, then it's just as reasonable to choose one as it is the other(IM)).
M
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Say I have a static cache and I sync on that cache whenever I access the database. This provides my Synchronization methods are not synchronized.
In that case even if I only have one instance of Data the methods in my Data class could get accessed by multiple threads at the same time. It makes no diference how many instaces of Data I have the Sync'ing is on the cache. Therefore I deduce that if you have a static cache and you sync on it, it doesn't make a diference if You have an instance of Data per connection or not.
Multiple instances of Data just give you the added advantage of tracking your clients locks at no extra cost.
Can you see what I mean or have I a major concept problem
Cheers
Tony
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
OTOH, in the multiple Data paradigm, Andy only has to wait to Barbara to lock record 1. As soon as she�s done doing that, then Andy can lock record 2, at exactly the same time that Barbary is modifying record 2.
In practice, of course, the time �lost� is immeasurable small.
Make sense?
M
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tony Collins:
Sorry for taking up you time Max,


Think nothing of it: I've happy to help.


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


True, but if they�re not synched, you�re open to other issues. You might want to do a search on this, as Jim and I hashed it out a while ago.
Regardless, my example may have been more confusing then helpful. Think of it this way. If Andy is currently search using Data(and there's only one Data instance), then Barbara can't also be searching using Data. That is, when the two search execute on the server, they must execute one after the other: not concurrently. However, with multiple Data instances, they can execute concurrently.
There�s also a McDonalds example in my book(chapter 4), where I discuss localized locking as opposed to general locking.
M
[ September 18, 2003: Message edited by: Max Habibi ]
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


I'm assuming your Adapter's book method was along the lines

Was this method synchronized?
M
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cheers Max, though I can't fathom out what the problem is if you sync on the cache for all accesses to the Database and don't have any synced methods.
I could not find your discussions with Jim have you any idea how long ago they where.
Tony
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tony,
Threadingwise, you're ok if you synch on cache for all accesses to the db. I thought you were only doing so for lock/unlock.
Did the second part of my example, regarding search, make sense? Of course, it's only effective with multiple instances of Data if you don't synch on cache for non-lock/unlock methods.
M
[ September 18, 2003: Message edited by: Max Habibi ]
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tony Collins:
Yeah it made sense I just couldn't understand if I'd made some drastic error with my design.


Seems like you've got all your bases covered.


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.


Actually, I'd say you did follow the simplier design.


Cheers for your help much appreciated.
If your ever local let me buy you a few drinks some time.

Cheers
Tony



Sounds like a plan,
M
[ September 18, 2003: Message edited by: Max Habibi ]
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the multiple data v one data instance part of your book is the only part that isn't really clear. I don't know if the feedback is useful or not.
Tony
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I could not find your discussions with Jim have you any idea how long ago they where.
I'm not sure which particular discussions we're talking about here, there ahve been lots. And some are in posts that where a bunch of different people are talking about a bunch of different things all at once (or in close succession) so I'm too lazy right now to go threagh them all. It's probably something in May-July of this year. Regardless though - most discussions of this point use the word "singleton" (and sometimes "multiton"), so if you search on that term you should find lots of past discussions. Some of them may even be clear. Enjoy...
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Max: I'm assuming your Adapter's book method was along the lines
//lock//refresh//update//unlock
Was this method synchronized?

More precisely, my book() method contained the lock-read-modify-unlock sequence, and no, the book() method was not synchronized. Thus, as soon as client A locked record #1, client B was free to lock record #2.
 
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, I am totally confused I 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
Actually its a moot point for me as my assignment states I have to allow multiple concurrent client requests and therefore MUST implement a locking system. Keeping my eye on those MUSTs!
[ January 17, 2004: Message edited by: morgan bath ]
 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by morgan bath:
Ok, I am totally confused I 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


Hi,
In attempting to answer your question, let me first give you the assumptions that my design
at this time probably will use:
One database file provided by Sun
referenced by RandomAccessFile
referenced by FileTalk
wherein, conceptually, and disregarding efficiency concerns, FileTalk does low-level
record reads and writes (perhaps reading 10 records at a time, for instance).
Now, as far as not corrupting the physical database file, FileTalk needs to have
its methods synchronized (or, as pointed out, just synchronize the parts of the
methods that do the actual reading and writing).
The reason is that you don't want your thread to stop when it has not completed
writing a record, or after it has moved the file pointer, and then have another
thread come in thinking it is operating on record N when the file pointer really
is somewhere in record P.
So, conceptually, if you synchronize all your methods in FileTalk, then you are
all set, no doubt. You are completely covered.
However, there is a problem with this.
1. Will Sun really give us full credit for this trivial locking scheme? Unlikely.
2. Does this teach us anything about threads, multi-threading, wait(), notify(),
and notifyAll()? A little, but not a lot.
3. And, as Andrew has pointed out, by synchronizing all the methods within
FileTalk, you implicitly lock the complete database file simply to operate on
one of its records.
Thus, above FileTalk, which in its important parts are synchronized,
you have the multithreaded BusinessTalk.
BusinessTalk is where we learn about the intricacies of using a mutex,
multiple muteces (where each mutex represents a record), and keeping
everything clean: that is, we learn about writing an application dealing
with concurrency issues, exceptions, and sharing objects between
competing threads.
I'd say that the vast majority of posts to this group deal with these issues;
and, for me, they are not trivial, but I am making progress in understanding
them.
Welcome to this group; I'm sure other's will answer your question in more
detail or answer some aspect I skipped. Also, feel free to look for recent
posts in this group, as again, this is a very hot topic, and a quite facinating
one.
Note that FileTalk and BusinessTalk are class names I made up; for the most
part, FileTalk might represent Data or one of its subclasses in your design.
Thanks,
Javini Javono
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Morgan,


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.


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 Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't have any source files in my assignment so im basically gonna use nio just to use the 1.4 aspect of java more. I havn't even started coding yet, and Im just spending time trying to identify pitfalls in advance and better my understanding of this hitherto undiscovered (from my perspective) side to java.
But my gut instinct at the moment is multiple instance DB with passive locking only. Active locking seems overkill for such a small project and seeing as it wasnt demanded I dont wanna even go there ... But the issue of what happens when a thread that is writing to a file is interupted is an interesting one, but unless the thread crashes or deadlocks is it really an issue if using multiple instances? With a locking system in place no two threads will write to the same area of the file (unless the code has design errors) and each instance has its own position (pointer) in the channel so never the twain shall meet.
Or did I misinterpret your file access concerns?
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]


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?
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I only use lock/unlock once and that is to implement the book selected record operation.
One of the requirements (if memory serves) is that the client must be able to book any of the records. In order to book any of the records I assumed that meant the client should be able to see all the records. So when my client GUI is displayed for the first time it implicitly does a find to retrieve all the records. It doesn't do this in a locked context; it gets all the record that are in the database, regardless of whether they're locked or not. I display all the records in the database, or a subset if the user enters search criteria. I display locked and unlocked records. There's no visual distinction between the two in the table. When a user tries to book a selected record that is when I use locking. I obtain the lock on the selected record, read it (to get the latest values from the database), update it, and unlock it.
So to get back to your questions:


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.


Yes.


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?


No, I'm not locking all the records only the selected record when the client is trying to book it. A client viewing a record does not preclude another client from viewing the same record. I do not use active locking, I only lock the record after the client has initiated the booking (not merely highlighting the selected record).


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?


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 Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


Which brings up an obvious question as to why the assignment insists the Database should include a search function as to be honest it would be a hell of a lot more efficient to have the client do it. Less networking. Really its not a search function at all but a filter function.
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.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Morgan,
It may have been misleading for me to use the word filter. When the user enters search criteria in my application he really is doing a search of records in the database file. If he enters search criteria he gets all the records in the database for which the search criteria match and in that sense it's a filtered view of the database. If the user doesn't enter any search criteria then he gets all the records in the database and in that sense it's an unfiltered view of the database. I didn't want to leave the impression that I only get the records from the database once and thereafter just filter that result set depending on the user's search criteria. Each time the user presses the Search button I return the records from the database file that meet the search criteria. In the event there are no search criteria, then the search returns all the records in the database file (according to my understanding of the instructions). So I would disagree with your statement that it's really not a search function; I think it is. I just think it can be viewed as a filter in the sense that you get all the records by default, and if you specify search criteria then you get a subset (or filtered view) of the database.


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.


I think a number of people have taken the same approach as you outline and were successful. It's a different path than I took, but there are many ways to skin this cat. It's one of the nice features of the exam: you get to do things the way you want to, the way that makes the most sense to you.
Hope this helps,
George
[ January 17, 2004: Message edited by: George Marinkovich ]
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, im an abstraction freak and I usually rely on colleagues to remind me when Ive gone too far
On the filter thing, i wasnt thinking that you had used a filter I was suggesting why on earth could I not use a filter instead of getting a responce from the DB each time? Advantage: less network traffic. Disadvantage: Data is less current. Seeing as the most dramatic change likely at any one time is a service you attempt to book has been booked (which is possible no matter what unless you use active locking) im not sure how drastic a slightly out of date data set actually is.
Actually I re-read my assignment and im not 100% convinced that isnt a viable option. They dont actually insist the search is on the DB, but on the data. And its mentioned in the user interface section ...

Why am I enjoying this so much? Its a mixture of work without pay and school all over again! I should hate this.
 
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Questions about Max's book, the sample project:
class "DVDDatabase" alows multiple instances, so what is the use of synchronized methods? If all the "synchronized" key words (except for methods reserveDVD and releaseDVD) were removed, would the class DVDDatabase work the same?
Because each physical file stores one DVD and every method in DVDDatabase that modify the DVD is wrapped by reservDVD and releaseDVD in class DVDDbAdapter, so I think all the "synchronized" key words(except for methods reserveDVD and releaseDVD) can be removed and the project is still thread safe.
Am I right? Can someone give a good explanation?
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good question, Im getting more confused the more I re-read this thread.
Seems to me that you really dont need to sync on anything except the object that stores the list of records LOCKED. In the lock(),book(),unlock() approach no thread can alter the DB until it gains a lock on the locked object list and finds the record it wants to alter is NOT there.
Seems to me that single or multiple instance it doesnt matter. Threads can never alter the same record concurrently because of the requirement for lock() to run all the way through, and any thread can read whatever records it wants except any records locked in the lock records list.
Does that make sense?
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MB: Seems to me that single or multiple instance it doesnt matter.
Actually, it does matter. Here is the difference.
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.
There have, indeed, been lengthy debates in the past discussing which approach makes more sense. Read them, analyze them, and make your decision.
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


But in single instance what stops you NOT syncing all methods and instead syncing on a static object other than Data? That way a static instance can have its methods run by more than one thread concurrently.

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.


All of them still leave me feeling im missing something. Instinct tells me multiple-instance DB is the way to go, but im having trouble logically defending it. And thats the crucial thing for this exam right?
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MB: But in single instance what stops you NOT syncing all methods and instead syncing on a static object other than Data? That way a static instance can have its methods run by more than one thread concurrently.
Well, that's another difference. With a single instance of Data, you don't need a static object within the Data. But here is another spin on that: the "single instance of Data" approach doesn't neccessarily imply that Data (or its sublcass) is a singleton. All it implies is that there is one instance of Data for a given database table.
All of them still leave me feeling im missing something. Instinct tells me multiple-instance DB is the way to go, but im having trouble logically defending it.
I don't want to push you in any direction, -- but if you can't defend your design, it's probably not a good design.
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agreed. I think im going with my head not my heart. I think single instance with a list of locked record numbers, and ill sync on this list for the lock and the unlock methods. As long as no thread can run the book(recNum) method until they have a lock on the list of locked records, checked recNum aint in it, inserted it and then dropped the lock Im 99% sure its thread safe. It might 'feel' odd but until I fault my logic Ill stick to it Thanks
 
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
reply
    Bookmark Topic Watch Topic
  • New Topic