----- Original Message -----
From: "John S. Gage" <[EMAIL PROTECTED]>
> >As for locking, the reason for a lock is to prevent multiple threads from
> >working on the same message simultaneously. A thread obtains a lock on a
> >message while it current works on it.... It doesn't make sense to write
> >this locking to disk because if the JVM dies, the thread dies, so the
lock
> >is irrelevant. If you had multiple JVMs working against a single queue,
> >then locking on the disk (or database) would be required.
>
> I guess the confusion that I have (and it is undoubtedly my fault) is why
> *all* the messages in the database have to be checked for their *locked*
> status if that information is not in the database. It seems inefficient.
Yes, it is very inefficient, but here's why (aside from not having enough
time to optimize this)...
Say I'm a thread that wants to check the spool for a message, and try to get
a lock on it if nobody else is accessing. Here's what the spool does...
checks the oldest message... nope, some thread has a lock on it
checks next oldest message... nope, that was a failed delivery attempt, and
I'm not supposed to try for 1 more hour
checks next... nope, some thread has a lock on it
checks next... nope, some thread has a lock on it
etc...
More than likely within some number (depending on your # of threads), there
will be a message that the thread can lock onto. However, it's entirely
likely that this isn't the case (you could have 100 threads for instance in
an extreme case, or a bunch of failed messages in the queue), so you need to
be able to keep looking through the queue. Also, it could be make the queue
smarter about skipping over messages that are marked as failed and not ready
to be retried.
Town can let you retrieve the first X records (say 10), but it can't really
retrieve the next X records. What I suppose you could do is retrieve the
first X records (say 10), if that fails, requery the database and retrieve
the first X times 2 records, etc... This would require some double
checking, but it's certainly better than retrieving 5000 records, just to
guarantee finding an unlocked/ready message. JDBC would be the best,
because you could retrieve the first X records, and then use the same query
set to retrieve the next X records, although some drivers may still be
retrieving the whole record set anyway. Any other ideas?
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
