Thanks for the clarification, Serge.

1) Maybe this information could be put into a package descriptor for Javadoc? 
(I'm not sure exactly what they're called, but if you include a file called 
"package.html" in the source directory, it gets used added in to generated 
javadoc for that package).

2) It seems like we've got a perfectly good message locking mechanism, but we 
need to optimise message retrieval. 
I can see 2 options (I'm sure there are more):
    a) If we're going to do a database write whenever we use a message, 
surely a "lastAccessed" date stamp would do the trick (no need to use a 
"locking" flag). A similar mechanism would allow us to delay further attempts 
at delivery.
    b) Possbily more performant (no extra db writes) is to maintain a 
thread-safe set of ids of messages which are currently being processed, and 
use a simple "messageId NOT IN(id1, id2, id3....)" in the SQL. (I've used 
this sort of mechanism before, and it worked fine with 1000 id's on an 
indexed column. I don't imaging we'll be processing more than 1000 at a 
time?). This mechanism could also be used to delay messages for re-sending 
(if necessary), by having a separate set of ids which are being delayed, 
together with the timeout required.

Just my immediate thoughts
ciao
Daz


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to