I've been refamiliarizing myself with some of the code, and would like to
get the RDBMS stuff working in the new Avalon/Phoenix architecture. I
believe someone has already started working on the user repository version
of this, so I'd be curious how he/she was planning to do this.
I think we all agree that Town isn't the right technology for James. The
two options that seem on the table are moving to pure JDBC or to Turbine
other database abstraction model. While I think Turbine would be great for
letting James automatically create the appropriate table structure, I think
it is overkill for what James needs. I think pure JDBC with a simple
connection pooling code is what we need.
1. James's database structure is very simple. The core of James has the
potential to use 2 unrelated tables. One for a user repository and one for
a message spool repository. The structure of these tables are very simple.
2. Users are already shielded from the database code by the UserRepository
and SpoolRepository API. This ease of use would really only help the one or
two developers who write the DatabaseUserRepository and
DatabaseSpoolRepository class.
3. We need a lot of control over how data is returned for performance
reasons. Two big limitations we are experiencing with Town (that I believe
we would have with Turbine and other abstraction layers) is the inability to
return parts of a ResultSet and to get streamed access to binary data. I
believe both of these are critical to increasing scalability and
performance.
Raw JDBC access would potentially make administration more complicated, but
I believe with documentation, this could be overcome. Then the only thing
we need is a JDBC connection pool code, and I happen to have one I can add
pretty easily. I originally developed it for Town and since made further
improvements it. I can take the 3-4 necessary classes and add this directly
into James and remove the town.jar library. It's also licensed in an ASF
license model, as opposed to a few open source JDBC poolers out there that
are GPL, creating licensing problems.
Any thoughts? I can throw the JDBC spool repository implementation together
pretty quickly using the old table structure.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
