This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:Locking - one data instance or multiple Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX:Locking - one data instance or multiple" Watch "NX:Locking - one data instance or multiple" New topic
Author

NX:Locking - one data instance or multiple

Bill Robertson
Ranch Hand

Joined: Mar 21, 2003
Posts: 234
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
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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 ]

Java Regular Expressions
Bill Robertson
Ranch Hand

Joined: Mar 21, 2003
Posts: 234
But do you feel the simpler design will get the passing grade.
I take simplicity over everything!
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
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
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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

Joined: Jul 03, 2003
Posts: 435
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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

Joined: Jul 03, 2003
Posts: 435
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
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

Joined: Jul 03, 2003
Posts: 435
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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

Joined: Jul 03, 2003
Posts: 435
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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

Joined: Jul 03, 2003
Posts: 435
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)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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

Joined: Jul 03, 2003
Posts: 435
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
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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...


"I'm not back." - Bill Harding, Twister
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
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.
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
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 ]

Morgan
SCJP (1.4), SCJD (1.4), SCWCD (1.3), SCBCD (1.3)
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
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
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
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 ]

Regards, George
SCJP, SCJD, SCWCD, SCBCD
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
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

Joined: Jan 16, 2004
Posts: 196
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

Joined: Apr 15, 2003
Posts: 619
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

Joined: Jan 16, 2004
Posts: 196
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

Joined: Apr 15, 2003
Posts: 619
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

Joined: Jan 16, 2004
Posts: 196
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.
Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
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?


Peter
Morgan Bath
Ranch Hand

Joined: Jan 16, 2004
Posts: 196
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

Joined: Oct 08, 2001
Posts: 2937
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

Joined: Jan 16, 2004
Posts: 196
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

Joined: Oct 08, 2001
Posts: 2937
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

Joined: Jan 16, 2004
Posts: 196
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 agree. Here's the link: http://aspose.com/file-tools
 
subject: NX:Locking - one data instance or multiple
 
Similar Threads
How to tidy up a swing listener program?
Static HashSet problem
stuck by lock
are instance variables thread safe ?
thread safety and synchronized.