Next part of problems Guys! :-)
1. Did you cope with the problem of re-registering RMI service? I mean did you prepare yourself for following scenario:
Server: startup
Client: runs application and connects to the Server
Server: shutdown
Server: startup
Client: search for records
??? - most likely connection error, because the location of remote object (service) has been changed.
2. Did you provide tips for every text field?
3. My interface is waiting for the cookie to update / delete / unlock of the record. My implementation creates a deadlock if ONE
thread blocks twice the same record one after another, like:
T1: lock RecNo 2
T1: lock RecNo 2
<deadlock>
Because I have a three layer architecture, the locks are managed by the business logic layer. The possibility of a deadlock can occur only if the programmer will not obey to the rules. Normal client / user of the business logic cannot create such a deadlock.
Should I be worried about that and work on it, or can I safely leave it that way?
4. Did you inform the user (in GUI) about how the filter works (logical AND, OR, exact match) or did you put it only in the user manual?
5. I am using a
as a mechanism for generating lock cookie. As far as I know, the first execution of
Math.random() creates a generator with particular seed, and every following executions use the create generator to get pseudo-random numbers. In my opinion if the generator is reused, and the value is multiplied by the range of LONG it is enough for the SCJD if it comes to randomization. What do you think?
6. Firstly in my data class in
long create(-) method I didn't throw DuplicateKeyException. By "throw" I mean that literally I didn't add "throws DuplicateKeyException" to the method signature. I assumed that this is still a valid implementation of the interface, as reducing number of exceptions is perfectly legal when overriding / implementing methods. After some thinking I decided to add the "throws DuplicateKeyException" to the method signature but remain with the idea of not actually throwing the exception from the method body.
I changed my mind, because I thought, that if they have a some kind of framework where they tests how the data class is working, they might have a catch block which will catch the DuplicateKeyException. If the method signature is not throwing it, it will not even compile, as it is a checked exception.
This is why I decided to finally just add the throws declaration to my create method signature in the data class.
Do you think it is a right choice?
7. I do not plan to add the 48 hours rule in my project.
Off Topic: be careful kids -
SimpleDateFormatters are not thread-safe and can really mess your day ;-)))
Cheers!