Thanks for your feedback. Comments below.
----- Original Message -----
From: "Oki DZ" <[EMAIL PROTECTED]>
> In addition to connection pooling, I think we'd need a superclass for the
> JDBCMailRepository (and the class should be a subclass of
> AbstractLoggable, as usual). The purpose for the class is for defining the
> SQL statements used throughout the class. In the future the class can be
> configured to read the statements from the config file. In doing so, the
> JDBCMailRepository could be easily adapted to whatever db backend
> currently used. Then, JDBCMailRepository would stand for its name; it's
> "JDBC", your class shouldn't be tied to any particular database server.
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? Also, how do you see a superclass being more flexible
(I don't understand the proposed class structure)?
> BTW, I have started looking at the JDBCSpoolRepository. I think it would
> be better if the list (the content of the result set) is stored in a
> cache; as I understand the code, the accept() method will wait for a
> "connection", then it retrieves the message list from the database. If the
> first message in the list can be locked (meaning no thread is working on
> it), then the message (name) will be returned; and the method will return.
> The loop will only continue if the messages in the list have been locked.
> Problem is, you'd have so many retrieval on the database; the lesser
> threads are already working on the spool, the more retrieval there would
> be. Meaning, there would be so much time spent for the (re-)retrieval.
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). 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?
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.
> This is a non standard JDBC feature, right? I think you shouldn't depend
> on it too much (besides, think about the users who get _mad_ at you
> because their drivers don't support pooling :-)
No it's not, but I think users would get much more mad at me for the
hardcoded username, password, driver, and JDBC URL if I acted like it was
finished. :) It's still in a proposal branch and hopefully will work its
way into the main branch before too long.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
