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]