[JBoss-user] (no subject)
unsubsribe ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] A little BMP philosophy/understanding
It seems that the JBOSS EJB container do need to implement the connection pooling and preparedstatement caching just because the JDBC driver already support them. Does the JDBC2.x and above support the connection pooling? Is JDBC2.x specification mention about the Preparedstatement caching? - Mike -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 4:04 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] A little BMP philosophy/understanding > Doesn't this defeat the purpose of caching and prepared statements? If you > close the prepared statement then the db connection goes away > right? So why > used a prepared statmenet at all, beacuse it is never really prepared? It > seems to me the cache would need to keep at least one of each prepared > statement used to be of any value. no, you should not cache statements. If you are using prepared statements, it is on the level of the driver to make sure that they are cached. a prepared statement should give you the same performance even if you close them in your code, since it is handled by the driver, not by the programmer, or by jboss. caching statements goes back to 1997 when the drivers did not do this for you. now a days, almost all of them do. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hansen, > Richard > Sent: Thursday, March 22, 2001 1:53 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-user] A little BMP philosophy/understanding > > > > Rick Hansen > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 22, 2001 1:25 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-user] A little BMP philosophy/understanding > > > > In the original JBoss 2.0 version the PreparedStatement cache was not > discarded after the connection was returned to the pool because more than > likely you might want to issue that one of these PreparedStatements again. > To make matters worse there wasn't an upper limit on the number of > PreparedStatement objects in the cache so things would continue to grow as > you prepared new SQL statements. If you happened to prepare the same exact > SQL statement then you received the previously cached PreparedStatement > object but otherwise you got a new PreparedStatement that was > also added to > the cache. This would continue until either a) the database > complained or b) > you ran out of memory which ever came first. On Oracle, for example, each > PreparedStatement takes memory on the database and once you hit 100 or so > the database throws an exception when you try to get another one. > > I patched the code by releasing the PreparedStatement cache when the > Connection was released and submitted that fix but I'm not sure it was > accepted. What really needs to happen is that the PreparedStatement cache > needs to be enhanced so that an upper bound can be established via a > configuration variable so that after x PreparedStatements have been cached > new PreparedStatements will push one of the old ones out of the cache. > > - Jon Harvie > > > > Mike Jau <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 03/22/2001 12:42 PM > Please respond to jboss-user > > To:"'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]> > cc: > Subject:RE: [JBoss-user] A little BMP > philosophy/understanding > > > > Could you give me some background information about the Preparedstaement > caching on the EJB container side? > > Since the connection get from pool need to return to pool once the > transaction done. I assumed that the resouce associate to this connection > should be released and the released resoure include the preparedstatement. > Later on, the create preparedstatement will be invoked again from > different > connection. How the preparedstatement cached is my question? > > > - Mike > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 22, 2001 12:10 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] A little BMP philosophy/understanding > > > > > Dan Christopherson wrote: > > > On Fri, 23 Mar 2001, Peter Routtier-Wone wrote: > > > >>> Someone from this discussion group indicate that container might cache > the > >>> PreparedStatement. > >> > >> I can't speak with authority on this, but that rings true. I'm guessing > that > >> interception doesn't happen for the setEntityContext() method and &
RE: [JBoss-user] A little BMP philosophy/understanding
So,
the caching of the PreparedStatement is stored in the database
connection context and is not shared between the database connection. I am
thinking a work around way and it may solve the caching issue. If we
have the "named connection" from the pool with the lifecyclye control to release
the PreparedStatement from the applicaiton which invoke the container specific
API, it probably can solve the problem.
- Mike
Jau
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Sent: Thursday, March 22, 2001 1:25
PMTo: [EMAIL PROTECTED]Subject: RE:
[JBoss-user] A little BMP
philosophy/understandingIn the original JBoss 2.0 version the PreparedStatement cache was not
discarded after the connection was returned to the pool because more than
likely you might want to issue that one of these PreparedStatements again. To
make matters worse there wasn't an upper limit on the number of
PreparedStatement objects in the cache so things would continue to grow as you
prepared new SQL statements. If you happened to prepare the same exact SQL
statement then you received the previously cached PreparedStatement object but
otherwise you got a new PreparedStatement that was also added to the cache.
This would continue until either a) the database complained or b) you ran out
of memory which ever came first. On Oracle, for example, each
PreparedStatement takes memory on the database and once you hit 100 or so the
database throws an exception when you try to get another one.
I patched the code by releasing the
PreparedStatement cache when the Connection was released and submitted that
fix but I'm not sure it was accepted. What really needs to happen is that the
PreparedStatement cache needs to be enhanced so that an upper bound can be
established via a configuration variable so that after x PreparedStatements
have been cached new PreparedStatements will push one of the old ones out of
the cache. - Jon Harvie
Mike Jau
<[EMAIL PROTECTED]> Sent
by: [EMAIL PROTECTED]
03/22/2001 12:42 PM Please respond to jboss-user
To:
"'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]> cc:
Subject: RE: [JBoss-user] A
little BMP
philosophy/understandingCould you give me some background information about
the Preparedstaementcaching on the EJB container side?Since the
connection get from pool need to return to pool once thetransaction done.
I assumed that the resouce associate to this connectionshould be released
and the released resoure include the preparedstatement.Later on, the
create preparedstatement will be invoked again from differentconnection.
How the preparedstatement cached is my question? -
Mike-Original Message-From: Bill Burke
[mailto:[EMAIL PROTECTED]]Sent: Thursday, March 22, 2001 12:10
PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-user] A
little BMP philosophy/understandingDan Christopherson
wrote:> On Fri, 23 Mar 2001, Peter Routtier-Wone wrote:>
>>> Someone from this discussion group indicate that container
might cachethe>>> PreparedStatement.>> >>
I can't speak with authority on this, but that rings true. I'm
guessingthat>> interception doesn't happen for the
setEntityContext() method andtherefore>> you actually create a
PreparedStatement rather than receiving one fromthe>>
pool.>> >>> Just for kicks, I gave it a try but
transactions weren't completed and>>> they'd just hang out there
forever, blocking every other persistence and>>> finder method
until they timed out.>> >> That would bollox lifecycle
management, and the described behaviourwouldn't>> be at all
surprising.> > This is also a common bean bug: 'close()' should
be called on every> resultset, statement, and connection in a finally
clause so that you know> it happens every time.> >> On
the other hand, I'd have thought that PreparedStatements would be
far>> less costly to manufacture than Connections, and therefore not
worth the>> overhead of managing a pool. I think I'll poke my nose
into the sourceand>> see what's there.> > There's
often communication with the database to create the> PreparedStatement.
That way it can pre-compile a query plan. There is a> prepared
statement cache in JBoss: in JBoss 2.0, it caused problems with>
Oracle's cursor limit (fixed in 2.1).I'm re-writing the minerva
PreparedStatement caching so it handles cursor limit better. I'll
submit the code tomorrow after I test
it.Bill___JBoss-user
mailing
list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user___JBoss-user
mailing
list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] A little BMP philosophy/understanding
Could you give me some background information about the Preparedstaement caching on the EJB container side? Since the connection get from pool need to return to pool once the transaction done. I assumed that the resouce associate to this connection should be released and the released resoure include the preparedstatement. Later on, the create preparedstatement will be invoked again from different connection. How the preparedstatement cached is my question? - Mike -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 12:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] A little BMP philosophy/understanding Dan Christopherson wrote: > On Fri, 23 Mar 2001, Peter Routtier-Wone wrote: > >>> Someone from this discussion group indicate that container might cache the >>> PreparedStatement. >> >> I can't speak with authority on this, but that rings true. I'm guessing that >> interception doesn't happen for the setEntityContext() method and therefore >> you actually create a PreparedStatement rather than receiving one from the >> pool. >> >>> Just for kicks, I gave it a try but transactions weren't completed and >>> they'd just hang out there forever, blocking every other persistence and >>> finder method until they timed out. >> >> That would bollox lifecycle management, and the described behaviour wouldn't >> be at all surprising. > > This is also a common bean bug: 'close()' should be called on every > resultset, statement, and connection in a finally clause so that you know > it happens every time. > >> On the other hand, I'd have thought that PreparedStatements would be far >> less costly to manufacture than Connections, and therefore not worth the >> overhead of managing a pool. I think I'll poke my nose into the source and >> see what's there. > > There's often communication with the database to create the > PreparedStatement. That way it can pre-compile a query plan. There is a > prepared statement cache in JBoss: in JBoss 2.0, it caused problems with > Oracle's cursor limit (fixed in 2.1). I'm re-writing the minerva PreparedStatement caching so it handles cursor limit better. I'll submit the code tomorrow after I test it. Bill ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] A little BMP philosophy/understanding
Someone from this discussion group indicate that container might cache the PreparedStatement. Could someone talk about the PreparedStatement lifecycle in the JBOSS EJB Container? I beleieve that will help us to understand the usage of the PreparedStatement in the EJB environment. - Mike Jau -Original Message- From: Jeff Markham [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 5:53 AM To: [EMAIL PROTECTED] Subject: [JBoss-user] A little BMP philosophy/understanding I don't believe I quite have an understanding of EJBs as most of the people on this list so I'd like to ask a couple questions on BMP EJB design best-practices. In all the examples I've ever seen of BMPs, every persistence and finder method both 1) finds a DataSource and gets a Connection from it and 2) instantiates a PreparedStatement. Before looking into EJBs, I just went to the database from a servlet via JDBC. In the servlet, I would get a Connection and do all my PreparedStatements in the init() method of the servlet. On any requests that required the services of any PreparedStatement, I'd synchronize clearParameters and run it. Couldn't this same concept be done in an BMP's setEntityContext() method? Couldn't I get the Connection and do all the PreparedStatements there? It just seems that by doing a PreparedStatement in each call to the BMP's persistence and finder methods, it defeats the purpose of a PreparedStatement. Just for kicks, I gave it a try but transactions weren't completed and they'd just hang out there forever, blocking every other persistence and finder method until they timed out. Thoughts? Feedback? Maybe I'm misunderstanding some fundamental EJB concepts. In any case, I'd like to know what the best practices are for BMPs. Thank you. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] PLEASE HELP : How to bind javax.transaction.UserTransaction
Is that mean that the TransactionContext propogation is not implemented? Also, does that mean that JTS is not supported yet? - Mike Jau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 3:06 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] PLEASE HELP : How to bind javax.transaction.UserTransaction Previous discussions indicate that this can't be done in JBoss and that supporting it would be non-standard. I wanted to do this too and ran into the same issue. If you just want to use a UserTransaction from code in the same JVM as JBoss, you have to use a session bean. You can't use the UserTransaction at all from a separate client JVM. At least that is my understanding. Someone please correct me if I'm wrong. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kirill Averianov Sent: Wednesday, March 21, 2001 11:41 AM To: JBOSS (E-mail) Subject: [JBoss-user] PLEASE HELP : How to bind javax.transaction.UserTransaction PLEASE HELP ! > How to bind javax.transaction.UserTransaction to the JNDI > at the JBoss startup ? > What JBoss configuration files must be changed for that ? > > > Thanks a lot , Kirill. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Which Jar file contains the javax.rmi.PortableRemoteObject class in Jdk1.2.2
Since I failed to compile the Interest sample program in jdk1.2.2 and could you tell me which *jar files is additional to jdk1.2.2 runtime environment? While I switch to jdk1.3 and set the JAVA_HOME=/jdk1.3, but compiled with the jdk1.2.2/bin/javac and it will fail while the compiler just look into the jdk1.2.2 runtime *jar file. So, make sure to use the match version of the compiler to avoid the problem I had. - Mike Jau -Original Message- From: JbossKnut [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Which Jar file contains the javax.rmi.PortableRemoteObject class Check the rt.jar under jdk1.3. :-) - Original Message - From: "Mike Jau" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 20, 2001 7:27 PM Subject: [JBoss-user] Which Jar file contains the javax.rmi.PortableRemoteObject class > Hi, > > I am trying to compile the "Interest" sample from the shipped Makfile and > has the following error output > > javac -classpath "/jboss/dist/lib/ext/ejb2.0.jar;." InterestClient.java > InterestClient.java:4: Class javax.rmi.PortableRemoteObject not found in > import > > Then I try to find this "javax.rmi.PortableRemoteObject" from all the jar > files from jdk1.3 and jboss/dist/lib/*.jar and jboss/dist/ext/*.jar, but I > was unable to find it. Could anyone tell me which jar file is missing and > where can I download from? > > Thanks! > > - Mike Jau > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Which Jar file contains the javax.rmi.PortableRemoteObject class
Hi, I am trying to compile the "Interest" sample from the shipped Makfile and has the following error output javac -classpath "/jboss/dist/lib/ext/ejb2.0.jar;." InterestClient.java InterestClient.java:4: Class javax.rmi.PortableRemoteObject not found in import Then I try to find this "javax.rmi.PortableRemoteObject" from all the jar files from jdk1.3 and jboss/dist/lib/*.jar and jboss/dist/ext/*.jar, but I was unable to find it. Could anyone tell me which jar file is missing and where can I download from? Thanks! - Mike Jau ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
