On Fri, 20 Jul 2001, Serge Knystautas wrote:
> The class is using the JDBC API and using very basic SQL that I can't
> imagine wouldn't work in a particular database. Can you give me examples of
> what's not portable?
I was thinking about possibilities; say, there's a need for joining the
Message table with another to prevent a particular user from sending out
email (his/her messages would be in the spool, but would be left
unprocessed).
>Also, how do you see a superclass being more flexible
> (I don't understand the proposed class structure)?
AbstractLoggable
JDBCMailRepository (contains the setup for the SQL statements)
MySQLMailRepository (the class that has the whizbang, specific MySQL
SQL statements; and all the implementation methods defined in
MailRepository)
> I see your point about the cache, but I think we'd have to figure out a
> strategy for re-querying the cache (not just a timing issue).
I think testing whether the cache has been emptied would be enough; if
empty, retrieve from db server (and fill the cache up until a certain
number of messages).
> It's easy to
> cache a list and pull from it as accept() threads can grab them, but how do
> we handle messages getting locked/unlocked by other methods?
A snippet from JDBCSpoolRepository.java:
while (rsListMessages.next()) {
String message = rsListMessages.getString(1);
if (lock.lock(message)) {
rsListMessages.close();
listMessages.close();
conn.close();
return message;
}
Locked state is obtained after getting a message from the list
(rsListMessages) and pass it to the lock object. If the messages in the
list were stored in a global cache, then you'd have the same thing;
except there would be no SQL query to the server. If this cache is
accessible by the threads that handle the spool, then everything would be
all right; all you'd need left is to add "synchronized" to the cache.
> Also, especially with the JDBC repository, I frequently will run a SQL
> statement to move messages from one spool to another... just another
> possibility to take into account.
Will there be any problem if the message_name's are looked up from the
(same) cache? I think a global synchronized cache will do the trick. This
cache should be set up right after James is started up, and accessible by
all the threads that handle the spool's contents.
TurbineGlobalCache class comes into mind; but problem remains. This global
cache would be the only cache available in your app (ie: James). You can't
have serveral "named" caches, so you may have some headache if you need
several global caches at once.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
