Hi,
i am still thinking about performance and how to improve it... Here are some
thoughts and wild guesses that may help to improve the product. I am always
talking of bean managed persistent entity beans (using orion 0.9.4 and an
informix database), but some of this could apply to container managed beans,
too.
I've been experimenting with rather complex beans for a while and found,
that the main performance killer is the setup/lookup of the jdbc database
connection. So my first impulse was to maintain myself a static hashed cache
(via the JNDI name) of database connections and to close them after they
were unused for a while (yes, i implemented all this for testing, including
a thread for cleanup and a lock mechanism ;-). This leads to a dramatic
improvement of performance (a quarter of the time !). But - ooops - after
rethinking this concept, it violences the transaction boundaries of the jdbc
connections. The transaction monitor seems to rely on the fact, that a
database connection (at least in the bean providers code, i don't know what
vodoo is done by the DataSource class...) does not live longer than the
transactions scope (and, what's more, that one connection may be used only
by one transaction at a time). So a jdbc connection must be sort of a
"child" of a transaction context (correct me, if i'm wrong - i read the spec
but did not prove it in detail). Well, a workaround could be to limit the
scope of a cached connection to a transaction context, which can be obtained
by the EJBContext, but - ooops - beans with container managed transactions
are not allowed to call the getUserTransaction function... (BTW, is there
any "legal" way to determine / distinct the transaction within we are
running ?)
Anybody read until here ? OK, now the suggestion: given a sort of wrapper
for jdbc connections (the DataSource class), would it be possible to
implement some kind of a cache on the server side ? I guess, it would be
worth spending some time on it, given the dramatic improvements of
performance (for example finding and instanciating a large amount of beans
stored in the same DB within one transaction).
Here is a guess how to do it:
The DataSource.getConnection returns a wrapper implementation of Connection,
kind of
public class OrionJdbcConnectionWrapper implements Connection
{
private Connection m_RealConnection;
// All functions of Connection must be implemented this way...
public someFnOfConnection(...)
{
m_RealConnection.someFnOfConnection(...);
}
// except for close (and maybe some additional constructor ?)
public void close()
{
// Unlock the connection within the cache, so it will be closed when
the transaction is completed
// by the server. Or do nothing and close all connections at the end
of a transaction.
}
}
and maintains a Hashtable of these connections, associated with the
transaction. If the same connection within the same transaction is
requested, DataSource first searches the cache. Since JDBC allows to create
multiple statements on one connection and we are always within the same
transaction, nothing illegal should occur.
Keep the good work,
Jens Stutte
PS: Since we are caching: i also introduced a cache for prepared statements
created within each cached connection - this gains another 10-20% of
performance. Given a wrapper class like guessed above, prepareStatement
could manage a hashed cache (within this connection), using the query
statement as hash key...
____________________________________________
[EMAIL PROTECTED], http://www.net-media.de
NetMedia GmbH
Schubertstr. 8
66111 Saarbruecken
Germany
fon: +49 (0) 681 - 37 98 80
fax: +49 (0) 681 - 33 89 3
