Are you by any chance using the raw DataSource by mistake?
>From inside user code you should use the source specified by ejb-location
(will be renamed to cmt-location since ejb-location is a bit misguiding when
it's used from servlets etc too). Look at the data-sources.xml's
documentation
for pooling settings (timeout, max-connections and so on).
Also - if performance is important CMP is recommended since it generally
yields
better performance (only use BMP when it is really, really needed).
/Magnus Stenman, the Orion team
----- Original Message -----
From: "Jens Stutte" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Saturday, April 01, 2000 12:54 AM
Subject: Some suggestions...
> 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
>
>
>
