Originally posted by Czarak Ynehac:
singleton (private constructor with getSingeltonInstace() method)
As a side note: it is my understanding that Sun do not have a test harness (yes, I do know that this contradicts what they say in their instructions). They do have automated tests that will confirm basic structure of your submission / method signatures of specified interfaces and classes, but that is as far as it goes. There has been some speculation that a test harness was too difficult to generate since Sun have not specified a constructor for the Data class (and there are many different constructors possible).
Also, the thurst of my post was a desire to move away from creating Data as a Singleton, so in the context of this thread I think this is a moot point.
The issue of clients instantiating Data with differet DB files is further confusing me. If we thought about all clients only using one DB file then one static collection in the Data class would suffice to track locked records across multiple instances of Data, but what about when there are multiple instances of data looking at multiple DBs?
No matter what you do, there is only one physical file on disk. Having multiple instances of the RandomAccessFile may or may not help concurrency - some operating systems allow multiple file pointers per file as long as they are working on different disk blocks or different pages, and some do not. Java makes no guarantees as to what will happen in this case.
If RandomAccessFile is made a class member of Data, does this reduce the concurrency of my application when there are multiple Data objects in existence? If RandomAccessFile is made an instance memeber of Data, does this invalidate my locking mechanism?
At the moment I am leaning towards making the RandomAccessFile a member variable of data as I'm tentatively thinking that this will not invalidate my locking mechanism and it will aid the concurrency of the application.