URLyBird - Lock problem

[Alexandre Baldo]

Hi guys!

My specification says:

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

What' f... does it means :?:

Thank you!!

[Alexandre Baldo]

After meditating about the subject I finally got it!

If the application is running in stand alone mode we will certainly have just one program accessing the database file (that was easy).
But my doubt was about the network mode. Now it is obvious that the only "program" that is accessing the database file is the server! And just one server runs at a time.
And just now I realized that is the server that will instantiate the class that manipulates the data (Data.java in my case). I don't know why i thought that every client would have to do so...

Sorry for the stupid question! ops:

But thanks anyway!!!

[christian combarel]

Hi !
It's not a stupid question !
Programs that access the database are the client threads. Each thread processes a client request (a search or a booking operation).
With URLyBird (as with most of the client-server systems), the end-client is the GUI.
Of course you can have many clients (many GUI) that want to access the database in local or networked-mode.
So you have to make sure that a write operation for a given record at a given time is allowed to one and just one thread.

[Jeffry Kristianto Yanuar]

The locking mechanism is very crucial in this certification, if your locking mechanism fails, you'll get the automatic fail.

Good Luck !!!

Jeffry Kristianto Yanuar (Java Instructor) SCJP 5.0, SCJA, SCJD (UrlyBird 1.3.2)

[Ulises Pulido]

christian combarel wrote:Hi !
It's not a stupid question !
Programs that access the database are the client threads. Each thread processes a client request (a search or a booking operation).
With URLyBird (as with most of the client-server systems), the end-client is the GUI.
Of course you can have many clients (many GUI) that want to access the database in local or networked-mode.
So you have to make sure that a write operation for a given record at a given time is allowed to one and just one thread.

Well my understanding was to allow writing access to the current thread if it is not affecting the same row as another thread so two threads can write at the same time if they are writing over different rows (records).

[mohamed sulibi]

hi;

So you have to make sure that a write operation for a given record at a given time is allowed to one and just one thread.

you must insure that only only only only one thread at a time will access(read, update, delete, create) the database file.

regarding the mode local or remote you must insure that your instance is valid for multi-threading accesses. here you can find many benchmark code to test your data class search about it.

therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

as business wise you can think in logical-record locking and use lock and unlock when you implement your business client class.

regards.
scjp, scjd in progress (from 1/8/2007 till now ).

[Ulises Pulido]

mmm... I just got confused, my understanding was to let all Threads reading operations at every time every moment and just to lock when writing over the file (create, update, delete) and for update and delete operations to also lock the record getting changed.

[christian combarel]

Hello,

my understanding was to let all Threads reading operations at every time every moment and just to lock when writing over the file (create, update, delete) and for update and delete operations to also lock the record getting changed.

Well, this is exactly what is required from Sun, in the DBMain interface for the lock method.

[mohamed sulibi]

hi guys;

there are two location on the project have to be synchronized:

1- when accessing the database file anywhere in the code and altering the RandomAccessFile pointer or get the length of the file unless you use local RandomAccessFile instance in every methods call, sure when you get the length you must synchronized.
2- when you implement your lock/unlock methods and use these methods in Data and in the client class and use the Data.

For cache implementation i post a new thread that may help you if you use the cache for data, here Cache Implementation.

regards.

[Alexandre Baldo]

Well, what I've decided to do is:

1) Make all methods implementations of the provided interface (DBAccess.java) 'synchronized'; In my case, the class that implements the interface providade by Sun is called Data.java;
2) I created a service class that has an instance variable of the type DBAccess wich I called 'database'. It was marked as 'private' and 'static'; So every object of my service class will share the same reference to the DBAcess object;
3) Since all the methods in Data.java is 'synchronized' (even the methods that just reads the database) I think I will get a thread safe solution;

What do you think!? :roll:

[mohamed sulibi]

hi;

for
1- please don't synchronized the hole methods but synchronized just the block of code where you alter the pointer and read data or where you get the length of the file, so you can get more concurrent access.

2- I don't like Data instance to be static if you obliged to do so, you can pass one instance to contractor of the service class... consider adapter design pattern.
BUT if you don't obliged to do so, you can create just one instance of the service and pass these instance in local or in the rmi registry.

3- Yes you will just get a thread safe accessing mechanism (CRUD operations) on the database file.

regards.