Aaron Mulder had some insight into this problem. Thanks Aaron.
Anybody know the latest stable version of the source code that I can
download and use?
Thanks,
Bill
-------- Original Message --------
Subject: Re: JBoss: maximum open cursors problem
Date: Tue, 6 Mar 2001 16:23:38 -0500 (EST)
From: Aaron Mulder <[EMAIL PROTECTED]>
To: Bill Burke <[EMAIL PROTECTED]>
The problem has been fixed in the current JBoss codebase.
Unfortunately, 2.0 was released before the fix. So I'm afraid your only
options are to change the code and recompile 2.0, or upgrade. If you want
to change the code, the easiest change is to disable the prepared
statement caching altogether. A more complex change would be to backport
the fix.
Aaron
On Tue, 6 Mar 2001, Bill Burke wrote:
> Aaron,
>
> Sorry to bother you, but you had an interesting reply to this problem
> back in October. I'm running JBoss 2.0-Final, on Linux with the Oracle
> thin JDBC drivers. I am currently the only concurrent user of JBoss,
> but we do have WebLogic running off of he same Database on the same
> machine using different JDBC drivers. After running JBoss successfully
> for awhile I get a maximum open cursors problem originating from
> JAWS,(if you want the stack trace just yell). The funny thing is, is
> that straight JDBC calls still work.
>
> 0. Is the max open cursors problem fixed in JBoss2.0-Final?
> 1. Does JBoss still cache PreparedStatements that JAWS uses?
> 2. How can I limit the amount of PreparedStatements/Statements in
> JBoss/JAWS, or even eliminate Statement caching altogether?
> 3. How can JBoss determine how many Statements to cache before it
> reaches Oracle's limits?
>
> Do you have any hints on how I can debug this further?
>
> BTW, I'm porting a mature Weblogic 5.1 application to JBoss.
>
> Thanks in advance,
>
> Bill Burke
>
> Your message from October 4th:
>
> We are aware of the max open cursors problem. That will be fixed
> before the final release. We cache PreparedStatements, and we need to
> have some configurable maximum size to avoid keeping so many open that we
> see errors like this.
> Are you aware that you can use Minerva outside jBoss? It is not
> dependent on jBoss in any way, and that may make your task easier. If you
> still want to manage connection rollback/commit manually, you should use
> the JDBCDataSourceLoader instead of the XADataSourceLoader, and that will
> leave out all the transaction and two-phase-commit stuff that you should
> not interact with. In fact, the XADataSourceLoader will probably change
> between now and the final release to throw an exception if you call commit
> or rollback manually.
> If you need help configuring this, let me know. It is quite
> similar to XADataSourceLoader, but not identical.
> Finally, I'm not sure what could be causing the memory leak you
> report (if it is more significant than the size of the extra
> PreparedStatement objects). We will need to investigate that.
>
> Aaron
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
