• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DB Reader Pooling

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
I am taking the URLyBird assignment. I implemented a DBReader Class that would hide all the complexities of reading the given specific format of the Data File. (One byte characters, 4-2 byte integers) etc.
This class exposes two methods
String[] readData(int recNo){}
void writeData(int recNo, String[] data){}

Now i had thought to have a Delegator that will use this class instance and delegate the CRUD methods of the DB interface. This class i call the DBManager. DBManager is a singleton so that there are no synchronization issues amongst the various DBManagers (And it is always better to have a single manager for anything ;-))

Here i fear that i would end up using only one reader and that will be a bad design. If one person is writing rec 1 then till he does so no one will be able to write to any other record since he will have the lock for hte DBReader instance.

Does any one have some hints on this one? Should i be implementing a DBReader Pool to get things straightened?

DBReader is a misnomer. It is more of a DBReaderWriter. i am going to change that soon to DBFileHandler.
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If one person is writing rec 1 then till he does so no one will be able to write to any other record since he will have the lock for hte DBReader instance.



Are you synchronizing on the write method of DBFileHandler?
I do not know if the URLyBird assignment requires to have a decoupled lockRecord(recNo) ... (B&S assignment does..).

If you use a pool of DBFileHandler, what do you synchronize on to maintain data integrity?
#1 #2 #3
Your control flow is : DBManager => DBFileHandler => actual data

and you might be maintaining data integrity by controlling #1 AND #2 (Even singleton DBManager will be shared by multiple RMI threads concurrently).
Is it better to control the data integrity in one place, possible towards the end of the control flow?

Gist is, what would you gain by making DBManager singleton?

Thanks
 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Are you synchronizing on the write method of DBFileHandler?
I do not know if the URLyBird assignment requires to have a decoupled lockRecord(recNo) ... (B&S assignment does..).

If you use a pool of DBFileHandler, what do you synchronize on to maintain data integrity?
#1 #2 #3
Your control flow is : DBManager => DBFileHandler => actual data

and you might be maintaining data integrity by controlling #1 AND #2 (Even singleton DBManager will be shared by multiple RMI threads concurrently).
Is it better to control the data integrity in one place, possible towards the end of the control flow?

Gist is, what would you gain by making DBManager singleton?

Thanks


I was thinking that If there would be only one DBManager then only the objects having access to DBManager will be able to use the DB File. Hence i will be able to make concurrent access to that file easier.

My Flow is something like this
Data (implements DB) -> Uses DBManager -> DBFileHandler -> Actual Data from File

In this flow Data has instances of DBManager that will help to read/write Record. I moved the actual data interpretation (8-byte characters and other details) to DBFileHandler. Synchronization now i have changed and created a separate Lock class that will hold the record number and the cookie. I synchronize on this lock object.

The data section is working fine but i would still want to know if there is anything wrong in making DBManager a singleton? I mena you seem to know more and i have not worked much on designing things.
 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another thing that made me make the DBManager Singleton is the fact that i have a LockManager which is a wrapper around a HashMap that will hold the Row Number as key and the lock associated with that row as the Value.
Using this hashmap i allow concurrent access to the records. So to avoid there being multiple copies of this LockManager having independent locks for each record i made the DBManager as a singleton so that all instances of DBFileHandler, LockManager and RecordFinder (Another class that helps in searching for a record) are single and do not affect the underlying database.

On a second thought i would rather make LockManager as a singleton and let the DBManager, RecordFinder and the DBFileHandler have multiple instances.

What do you say?
 
Josephx Rainerd
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Synchronization now i have changed and created a separate Lock class that will hold the record number and the cookie. I synchronize on this lock object.



What if you make ONLY the Lock class singleton and let the rest have multiple instances ? You would be controlling the concurrency from one point towards the end of the flow. Its just a suggestion ...
I am no expert in design..
 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm Locks will have to be there for all the Records and so cannot be Singleton. But yes i would make the LockManager singleton so that there is no conflict.
Thanks
 
Josephx Rainerd
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

created a separate Lock class that will hold the record number and the cookie. I synchronize on this lock object.



Since you are locking on 'Lock' object , which holds record number and the cookie, why do you need LockManager to be singleton?

For example,

//A sigleton class
class Lock {
Collection someCollection < recordNo, cookie>
}

You can happily lock a record by adding an entry to the someCollection after obtaining lock on the single instance of Lock object.
Yes, the collection would contain <recordNo, cookie> for all locked records in the system.

Hope it makes sense.
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sam,

As far as I understand you you have a work flow :
Data -> DBManager -> DBFileHandler -> File

One thing is still not so clear : Can you change your db file ?

The Singleton pattern is quite dangerous in multi thread environment, so use it carefully.
If your DBManager is just a simple factory (and a singleton), or better static factory -used only to create FileHandler instances I don't think that you need to synchronize it.

I don't understand why you need a singleton - can you detaliate your decision(s) ?


Regards,
Mihai
 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually what i have done is that i have a Lock class that can be locked and unlocked. This lock has to be created for each record and so i cannot use Josephx Rainerd's solution. (I do not have a collection)


LockManager has the collection of Locks for each Record. (A HashMap). This LockManager will take care of all the logic required for locking and unlocking records for a given Record Number.

Now here is the trouble. There could be more than one instance of LockManager and that would mean that there are more than one Locks for the same Record Number. I do not want that to happen and that is why i wanted to make that as a singleton.
But as a good design i thought that this LockManager has nothing to do with the rest of the Code. I mean that this class could generically be used with any other application and that is why application specific logic (that only one instance must be present to avoid conflicts) must be present in DBManager.
DBManager is a class that uses the LockManager alongwith the DBFileReader to allow concurrent Access. So i thought of making DBManager itself singleton so that all the lower classes are reusable (Some other app may need two Lockmanagers to handle two separate sets of data)

So please could you suggest me as to which one must i make (if at all) a Singleton. I now think that none of them need to be singleton as it will never be instantiated twice.

And BTW yes the DB File can be changed. DBManager takes an input parameter specifying the File name and that is sent all the way down to the DBFileReader

Thanks a lot for your attention folks
reply
    Bookmark Topic Watch Topic
  • New Topic