First off, I'm very new to James and since I haven't been able to get the
last stable release out of CVS yet, I'm forced to sit on the sidelines and
watch james-dev and james-user. However, I have learned some things and
have thought about how I would have to make changes if I wanted to increase
performance.
>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.
This is what struck me originally when I heard of all the abstraction going
on. It doesn't seem like a very complex system is needed, since James
doesn't really have complex database requirements!
>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.
Very good point.
>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.
I'm still not 100% clear on how the locking of records works (it almost
sounds like it uses Java's thread locking mechanisms rather than locking by
setting a flag in the DB). However, If the engine has to periodically
re-read all the messages in the spool just to send some of them out, then
I'm all for anything that will turn that around. It just won't scale
without doing something about this. If someone could explain again how
this works, I'd appreciate it.
>Then the only thing
>we need is a JDBC connection pool code, and I happen to have one I can add
>pretty easily.
Again, I'm just not clear on how database connections work now. It seems
to me that there can only be one connection retrieving spool messages,
because otherwise locking in memory wouldn't work and each thread that has
a connection would retrieve the same messages and send them again.
>Any thoughts? I can throw the JDBC spool repository implementation together
>pretty quickly using the old table structure.
Go for it!
I know that I would really like not having to redesign this part of James
so that it scales and I'm sure others feel the same way.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
