Hi Phil, hi Amardeep!
Thanx a lot for your input!
First of all I think that a clear design also has to be quite easy to understand (Phils reasoning). Even if there are some more interfaces/classes a rookie would have dismissed. Second: I won't write crappy software on purpose if some IT manager states "Sooner or later we kick it anyway!" So I'd say I'm looking for the hard way
Eventually it all comes down when you're justifing your approach (and list the alternatives).
What counts: For my first shot I AM a 3-tier supporter:
Database service and business service will go to the RMI registry (or local), lock/unlock will be hidden from the business layer (sorry Amardeep). I don't want to run into threading issues. As I understand the specs, RMI does not guarantee handling two or more calls of one client with the same thread. How could that go anyway, if a thread has to wait. I'm going to use a mutex implementation of an abstract semaphore interface. The mutex enforces real strict locking: Only the owner (thread) of a mutex can unlock it. Think cookies won't be really necessary in that case. Maybe I change the locking in favor of cookies. Considering that I even might change to a 2-tier architecture
O.k. it time to code
If I run into trouble you will know, when everything's going fine, I let you know, too.
Thank you very much again for your input.
PS: The mere asking and considering in this forum with all you guys, gets my thoughts sorted out.