Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!

Mark Thomson

Greenhorn
+ Follow
since Jul 20, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mark Thomson

Thanks for your reply Peter,

I know letting a singleton take a parameter is bad but I can't see how I can pass through a parameter to my singleton??

Now for the schema singleton I was thinking of using the properties file, but I don't like the idea of the app starting up for the first time, writing the dbFile location to a property file and then having the singleton read from the property file. Could have some threading issues etc.

Any ideas??
When i get to my RMI part i am planning on using a DBAdapter factory to return me new instances of my Data class ( underlying ) so i reckon I will be ok in that respect
Ok, after much debate I reckon I will go with the following solution for my Data Access Layer.

My data class has the following members:

1. Shared single RAF for file access and locking
2. Shared single Collection for record Locking
3. Shared DBMetaData class ( singleton ) for establishing db schema information
4. Shared CookieGenerator class ( singleton ) for generating unique lock cookies

You can create multiple instances of Data Class

My Data class is wrapped inside a DBAdapter class ( using the SUN DBAccess interface as reference type ) which implements a DBClient interface ( Adapter pattern )

Now I am debating wether to extract the File IO jobs ( read record / update / create record etc ) into a DbIO class. Do you think there is any benefit in this??

Also, currently my DBMetaData class ( singleton ) is responsible for configuring itself ( reading in the db schema and setting instance vars etc). Now i am not sure wether to leave this or to just use the DBMetaData class as a holder and give my Data/DbIO class( if i go down that route ) the responsibility of reading in the db schema??

Please let me know what you think.
Thanks, I reckon i will wrap the low level exceptions up in my own exceptions and propogate those up to the calling class

Now after some long and hard thinking I reckon I am going to make my Schema class a singleton rather than access via a factory. I will have a getInstance(String fileName ) method. Now i don't really like this implementation of the singleton pattern but i reckon its the safest way to go.

Does anyone have concerns about forcing a singleton to take a parameter in the getInstance method??
I am getting to the stage where i am thinking about the locking solution to be implemented in my B&S solution.

Please comment on my suggested approach and my questions.

1. I want to have multiple instance of my Data Access class. Each instance will have 2 static members. A RandomAccessFile and a collection ( to store my locked records)

1. Physical locking

For physical locking I will be synchronzing on the RandomAccessFile object shared across all instance of Data class

2. Record Locking

For record locking I will be using the static collection

WHen i write / update / delete a record I will follow the process below:

1. Lock record
2. Lock file
3. Update File
4. Unlock File
5. Unlock record

Now i am a little worries about this approach in terms of deadlocks. From what i understand there is no way this locking can cause a deadlock as the File and record locks are mutually exclusive. Is this correct??

I am also a little unsure of implementing the Data layer in this way ( multiple instances ) as I am ultimately locking on a single instance of my RandomAccessFile. ( not allowing concurrent reads / writes etc )

Any thoughts here???

I suppose I don't want to have multiple RansomAccessFile objects as I am worried about corrupting the underlying file. Is this a valid concern if I was to use multiple RandomAccessObjects??
I want to have a DBSchema class that basically stores my db schema information and also returns me a single instance of a RandomAccessFile.

Now I can't decide between implementing as follows:

1. Implement DBSchema as a singleton. Now the issue I have is that I want the DBSchema object to be responsible for reading in the schema from the dbFile so it will need to get hold of the file path. To do this I need to have a static method, say init(String dbPath) and then some boolean flags ( or throw exceptions )to say if I've already called init() on the singleton. Now I don't really like using the singleton pattern in this way as I am forced to have to make sure I call init() before I call getInstance() to get hold of the singleton DBSchema just to pass in some config variables to the object.

2. Return DBSChema object from a factory. Now i would use a singleton Factory that then takes in a param ( db file path ) and maps this to a schema object. To make sure I have a singleton schema object my Factory will use a hashmap to store the dbFile path against the object. If an object exists for a certain file path then I just return the object. Now the thing I don't like about this is that I am only ever creating a single DBSchema. Its not like I have multiple types of Schema that the factory needs to return. So its a bit of a waste of a factory ( although i suppose its good for future multiple SChema's )

Thoughts on either choice will be appreciated as I can't decide???

Now for a quick Exception question

3. Say I have a singleton class that creates randomAccessFile. Should i propogate any exceptions e.g FileNotFoundException up to the calling class ( the class that calls instance() or should I deal with them in the singleton??
I am going to use an adapter pattern but am usure how to fit it in bearing in mind that I am forced to already implement an interface in Data.java class

I was hoping to have the following

1. DBClient Interface - interface to expose only business methods to client object

2. DBAdapter Class - Implements the DBClient Interface and wraps the lock / unlock calls before calling the underlying Data class. This class contains an instance of Data.java .

3. Data.java ( as required by Sun specs ) implementing DBAccess interface ( also as required by sun specs )

I know my Data.java class needs to implement the DBAccess interface but I can't see how that DBAccess interface helps me with my suggested implementation. I suppose my DBAdapter class can have a reference of type DBAccess instead of Data but I can't see the benefit of this. Any thoughts??
I am just deciding how to implement my Data Access layer and have the following question.

My assignment states

Your data access class must be called Data.java, must be in a package suncertify.db and must implement the DBAccess interface



now in the spec for the interface DBAccess the javadoc comments for the lock method states


//Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.



Now it mentions a client and kind of points towards the fact that a client will access this interface directly.

Now I was hoping to implment this data access layer using the Adapter pattern where my clients access the Database via the adapter interface I define.

Now after re-reading the spec I am not so sure

Do I have to expose the DBAccess interface to my clients or can I wrap it up within my own interface ( as with the adapter pattern )??

Your thoughts will be most appreciated
Guys,

I just want to clarify what I am attempting to do. Your thoughts would be appreciated.

I am going to implement the following:

1. Each client has its own instance of a DBAdapter class. This class controls locking, access, unlocking. My Data classes methods are synchronized but I have multiple instances of my Data class so concurrent writes will be allowed as I am only locking on a static collection not the database file itself

2. I am using this static Collection to keep track of my locked records.

Now my big question is regarding the writes.

If I am locking at a record level, not a database file level then I will be allowing say 2 clients to update 2 different records at the same time. Is this how it should typically be implemented??

I am just worried about how concurrent writes ( concerning different records ) may affect the integrity of my database file.

Hope this clarifies my last post.

Thanks in advance
The only part I can find from the assigment that details concurrent request states

" You may assume that at any moment, at most one program is accessing the database file"

I am going to take it that I'm ok for concurrent writes to the database file only when dealing with different records.

Has anyone had any problems with file corruption etc, when perfoming concurrent writes?
I have a couple of questions regarding locking

1. Do i need to look after locking on a file access level as well as on a record level?

In the DVDDatabase example in the SCJD Exam book ( Habibi etc ) they implement a seperate DVDDatabase instance per client - in this way I can only see that records get locked ( using a static collection as a monitor and id holder ) not access to the file. Even though all methods in DVDDatabase are syncronized there are multiple instances of DVDDatabase so 2 clients could access two different records and update the database file at the same time. I am assuming that I shouldn't be allowing concurrent writes on the database file??

3. If I implement my database access layer using the Singleton pattern ( and making all methods synchronized ) then I can't see a need to lock individual records as only one thread will be able to access the database at one time.

Your thoughts on the above will be appreciated.

I am planning to architect the system with the following components

1. GUI
2. Server
3. Database Layer

Now in network mode the GUI access's the server via the RMI Interface. In Non gui mode the GUI access's the servers code directly, bypassing the RMI interface altogether ( as per the spec )

Now in the spec SUN mention the following:

quote: The mode is selected using the single command line argument that is permitted. Architecturally , this mode must use the database and GUI from the networked form, but must not use the network server code at all.



Does this mean in non-networked mode my GUI has to access my Database layer directly and not access the server code at all. Or does it mean I must not use the Server RMI interface, but I'm ok to access the actual Server methods??

--------------------



Can anyone clarify?
I am planning to architect the system with the following components

1. GUI
2. Server
3. Database Layer

Now in network mode the GUI access's the server via the RMI Interface. In Non gui mode the GUI access's the servers code directly, bypassing the RMI interface altogether ( as per the spec )

Now in the spec SUN mention the following:

The mode is selected using the single command line argument that is permitted. Architecturally , this mode must use the database and GUI from the networked form, but must not use the network server code at all.



Does this mean in non-networked mode my GUI has to access my Database layer directly and not access the server code at all. Or does it mean I must not use the Server RMI interface, but I'm ok to access the actual Server methods??

Just to clarify, I see the collection of configuration data as a seperate step prior to running the application so no matter what mode I use, a dialog pops up asking for the relevant config data for that mode. If a suncertify.properties file exists, the fields are filled in with the data from the file.



I like that idea and i reckon I am going to go with this GUI no matter what mode the system is being run on.

I am also now making the assumption that if a remote database is to be used then the GUI will request an IP address and port no. Have you guys also made that assumption??
Having just read and re-read the Bodgitt & Scarper assignment I have a couple of questions regardinb the architecture of the system.

Now I understand there are three options in terms of how the application can be run:

1. server mode - I assume this just runs the server with no GUI???
(passing commandline option mode=server)

2. alone mode - I assume this runs the server and client in a non-networked environment??
(passing commandline option mode=alone)

3. no mode - I assume this means we are running in network mode and thus we are connecting to an already running server???
(not passing any command line option )

Are my assumptions along the right track??

In regards to pint 1. The assignment also mentions:

'The program must allow the user to specify the location of the database file, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely'

Does this mean that the 'server' needs to have a GUI component?? otherwise following the statement that were not allowed to pass any extra command line parameters in, I'm not sure how the server would know where the database lives.

Also the part:

'and it must also accept an indication that a local database is to be used'

Does this mean that the user needs to be able to specify the location of a remote database?? if so I'm not sure how that would be achieved

Any advice will be appreciated