On Thu, 6 Sep 2001, Serge Knystautas wrote:
> I'm pretty sure the connection isn't used (or held open) until the
> writeMessageTo() is called. You're implying that if you have 20 messages in
> your (JDBC managed) inbox, you have 20 open db connections. I'm almost
> positive this isn't the case, and if it is, it clearly needs to be fixed.
I see, there's no problem in JDBCMailRepository regarding the db
connections, because the messages are always copied to local filesystem.
In JDBCMailRepository.retrieve():
MimeMessageJDBCSource source = new MimeMessageJDBCSource(this, key, sr);
MimeMessageWrapper message = new MimeMessageWrapper(source);
mc.setMessage(message);
rsMessage.close();
retrieveMessage.close();
conn.close();
return mc;
My problem arises from the use of db connection pooling and without local
copy; I couldn't return the connection promptly right the mc.setMessage(),
because the writeMessageTo() would be done long after the repository's
retrieve() method has returned. And yet, I couldn't rely on the gc to
return the db connection to the pool because it would be too long (ie: we
don't know when). But I think it is okay now, in the
MemeMessageJDBCSource, I return the db connection to the pool in its
finalize() method, and somewhere in other classes, I would just set mc
(any MailImpl) to null and do System.runFinalization(). (This is why I
like Java.)
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
