DatabaseManager - design decision

[Makeshkumar Subramaniam]

hi,
I have created a worker class called DatabaseManager which does following:

1. managing recordCache map (instance variable)
2. managing randomAccessFile for read write (instance variable)
3. reading schema details
4. reading data into recordCahe when object is created for DatabaseManager

is this design okay? or i should delegate the randomAcessFile stuffs to a new class ?

And I have some questions on (nested?) synchronization. please advise me if following code would create problem in multi-threading? :

//methodA
methodA{
     synchronzied(raf){
          methodB();
     }
}

//methodB
methodB{
      synchronized(raf){
           doSomething()
      }
}

also,

// I assume that following scenario may not create any problems. but is it good to code like this (i mean exam point of view) ?
synchronized(recordCache){

sychronized(dataBase){

}

}

Thanks,
Makesh.

[Makeshkumar Subramaniam]

Guys,
I think the above scenario is okay. I'v written following code and tested it.

public class NestSyn {

	
	private Object lock = new Object();
	
	private Object cache = new Object();
	
	
	public void methodA(){
		synchronized (cache) {
			System.out.println("cache start");
			synchronized (lock) {
				System.out.println("MethodA");
				methodB();
			}
			System.out.println("cache end");
		}
		
	}
	
	
	public void methodB(){
		synchronized (lock) {
			System.out.println("lock start");
			synchronized (cache) {
				System.out.println("MethodB");	
			}
			System.out.println("lock end");
			
		}
	}
	
	
	public static void main(String[] args) {
		
		NestSyn nestSyn = new NestSyn();
		for(int i =0; i<100; i++){
			new ThreadA(nestSyn);
			new ThreadB(nestSyn);
		}
		
	}
	
	
}


class ThreadA implements Runnable{

	NestSyn nestSyn;
	
	public ThreadA(NestSyn nestSyn){
		this.nestSyn = nestSyn;
		run();
	}
	
	@Override
	public void run() {
		
		nestSyn.methodA();
		
	}
	
}
class ThreadB implements Runnable{

	NestSyn nestSyn;
	
	public ThreadB(NestSyn nestSyn){
		this.nestSyn = nestSyn;
		run();
	}
	
	@Override
	public void run() {
		
		nestSyn.methodB();
		
	}
	
}

Now, my question is : coding like this (nested synch) would have any impact in the score ?

[Roel De Nijs]

Makeshkumar Subramaniam wrote:I think the above scenario is okay.

That's wrong, you will certainly risk a deadlock! And as a second (very important) remark: a real thread is started with its start-method, not with run-method!

Take a look at this scenario: when threadA gets the lock on the cache-object and then it moves back to the runnable state, threadB starts running and gets the lock on lock-object and then threadB moves back to runnable state. And this scenario is simple proven with following code

public class NestSyn {
	private Object lock = new Object();
	private Object cache = new Object();

	public void methodA() {
		synchronized (cache) {
			System.out.println("cache start");
			try {
				Thread.sleep(100);
			} catch (Exception e) {
			}
			synchronized (lock) {
				System.out.println("MethodA");
				methodB();
			}
			System.out.println("cache end");
		}
	}

	public void methodB() {
		synchronized (lock) {
			System.out.println("lock start");
			try {
				Thread.sleep(100);
			} catch (Exception e) {
			}
			synchronized (cache) {
				System.out.println("MethodB");
			}
			System.out.println("lock end");
		}
	}

	public static void main(String[] args) {
		final NestSyn nestSyn = new NestSyn();
		new Thread(new Runnable() {
			public void run() {
				nestSyn.methodA();
			}
		}).start();
		new Thread(new Runnable() {
			public void run() {
				nestSyn.methodB();
			}
		}).start();
	}
}

Output:
cache start
lock start

And the program will never end!

[Makeshkumar Subramaniam]

Roel De Nijs wrote:
And as a second (very important) remark: a real thread is started with its start-method, not with run-method!

oops. good catch. Thank you. i was bit sleepy last night

Roel De Nijs wrote:
Take a look at this scenario: when threadA gets the lock on the cache-object and then it moves back to the runnable state, threadB starts running and gets the lock on lock-object and then threadB moves back to runnable state. And this scenario is simple proven with following code

Okay. I think I got

basically when the DatabaseManger initializes, I just wanted to do read all record from disk and put them into cache.

synchronized(raf){
     
     .......
     //reading all the records from disk

     synchronized(recordCacheMap){
           //writing  records into recordCacheMap
     }

}

and I've some methods writing things from cache to disk.

synchronized(recordCacheMap){
     
     .......
    
    //reading  records from recordCacheMap

     synchronized(raf){
            //writing them to disk
     }

}

so this scenario, I assume, exactly matches with your code...

Now that I'll have to think over a different approach then !

Thanks for your time !

[Roel De Nijs]

You have to make sure that you always synchronize on objects in the same order.

So when methodA has

synchronized (cache) {  
   synchronized (lock) {  
   }  
}

then methodB should also have

synchronized (cache) {  
   synchronized (lock) {  
   }  
}

and the program will end normally, without deadlock

But if you have such nested synchronized blocks, why not synchronize the complete methods?

[Makeshkumar Subramaniam]

But if you have such nested synchronized blocks, why not synchronize the complete methods?

Thats what exactly I've done...
also have executed the Data Class testing program found here. (with almost 5000 threads ! )

It'd executed well without any problem (deadlock).


Thanks