Multithreaded connections and timeouts

[Luc Feys]

Hello,

I am working on the B&S assignment and have finised and tested the database server classes. Everything works fine, but as I am finishing up the documentation of these classes a few alerts popped up in my head.

1) I am using a timeout in my lock method, but am not sure if my specs allow me to.

Here is the spec of my lock method

// 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.

But since I have a timeout, I had to change the last sentence in the documentation of the lock method of the DBAccess interface to the following

until the record is unlocked or the maximum waiting time has
elapsed, whichever happens first.

Should I not use the timeout in my locking because this breaks my specs or could I get away it by argumenting my choice in the 'choices.txt'?

2) I have a connection factory that creates a new connection for every client using a shared instance of a TableFileManager and TableLockManager. Both those *Manager classes are thread safe, but the connection objects
themselves not, so each connection should be used by a single thread only. I have documented this in the javadoc. Is this allowable or should I make my connection objects themselves thread safe too, so they could be used for example in a connection pool?

I would really appreciate your suggestions on this matter.

Thanks in advice.

Luc Feys

[Alan Mc Kernan]

1. I dont think you should use a timeout - its against your spec.
2. I think this should be safe enough once its well documented.

[Oricio Ocle]

Hello,
regarding timeouts:
i don't think it's necessary to change the comment since when a timeout is reached, the record is unlocked and it's perfectly compatible with the current comment.
I am using timeouts too, but my scenario is cookie-based. Implicitly my specs are guiding to do not identify clients (IMO).
But if you have a connection factory, why to use timeouts?
you have an excelent scenario to identify clients and avoid deadlocks serverside, and perform server callbacks in order to identify orphan locks.

Regards
[ March 30, 2006: Message edited by: Oricio Ocle ]

[Luc Feys]

Oricio,

Thanks for the reply, but I am not using the timeout to release lock's that are held too long, but to avoid that a thread calling the lock() method would wait indefinitely for the lock to be released. So the lock is not released when the timeout occurs, but the calling thread just stops waiting for it to be released.
To identify my clients, I have to use cookies too. So my connection factory is not used to identify clients.
In fact, I don't really need the timeout's to avoid deadlock in my scenario, since I am planning not to expose my database layer to clients. Instead, I want to expose my mid-tier application layer on the server side, which will take care of all the locking so deadlock's can't occur (except if I mess up my application layer )

But thanks to your and Alan's suggestions I think I've have made up my mind. I will remove the timeout from the lockManager. And in my 'choices' document I will use the argument "that my spec's don't allow me to use a timeout in the locking" to defend my choice of not exposing the database layer to clients to prevent deadlocks.

Thanks a lot.

Luc Feys
[ April 03, 2006: Message edited by: Luc Feys ]

[Luc Feys]

Hello,

I gave this whole lock timeout problem another look during the weekend and I don't feel comfortable with the idea of not providing any way to prevent my clients from hanging when they are waiting for a lock that might never be released.
I feel like my locking solution would not be complete if I did not protect my clients against "deadlocking" while waiting on a lock that is held by a client that crashed or lost its network connection before it could unlock the record.
I would like to keep the timeout in my lock method anyway, but would not mention it in the documentation as part of the lock method functionality. After all it's not really functionality, just some kind of protection mechanism in my database, like you can get an OutOfMemoryError when working with any Java application.

Could anyone share his thoughts on this?

Thanks a lot.

Luc