Callable Statement Cache Size

Hi all,
while using some dinamyc store procedures I get in the following error:
[BEA][SQLServer JDBC Driver]Value can not be converted to requested type.
I'm using WL8.1 and Sql Server 2000.
Store procedure contains two different queries where table name is a store procedure's
parameter.
The first time it works great, after that I always have this error:
Reading bea doc's I found
There may be other issues related to caching prepared statements that are not
listed here. If you see errors in your system related to prepared statements,
you should set the prepared statement cache size to 0, which turns off prepared
statement caching, to test if the problem is caused by caching prepared statements.
If I set prepared statement cache size to 0 everything works great but that does
not seem the better way.
Should we expect Bea to solve this problem?
Or whatever else solution?
such as using JDBCConnectionPoolMBean.setPreparedStatementCacheSize()
dynamically ?
thks in advance
Leonardo

caching works well for DML and thats what it is supposed to do. But it looks
like you are doing DDL , which means your tables might be getting
created/dropped/altered which effectively invalidates the cache. So you
should try to turn the cache off.
"leonardo" <[email protected]> wrote in message
news:40b1bb75$1@mktnews1...
>
>
Hi all,
while using some dinamyc store procedures I get in the following error:
[BEA][SQLServer JDBC Driver]Value can not be converted to requested type.
I'm using WL8.1 and Sql Server 2000.
Store procedure contains two different queries where table name is a storeprocedure's
parameter.
The first time it works great, after that I always have this error:
Reading bea doc's I found
There may be other issues related to caching prepared statements that arenot
listed here. If you see errors in your system related to preparedstatements,
you should set the prepared statement cache size to 0, which turns offprepared
statement caching, to test if the problem is caused by caching preparedstatements.
If I set prepared statement cache size to 0 everything works great butthat does
not seem the better way.
Should we expect Bea to solve this problem?
Or whatever else solution?
such as using JDBCConnectionPoolMBean.setPreparedStatementCacheSize()
dynamically ?
thks in advance
Leonardo

Similar Messages

  • Java.sql.SQLException: Statement cache size has not been set

    All,
    I am trying to create a light weight SQL Layer.It uses JDBC to connect to the database via weblogic. When my application tries to connect to the database using JDBC alone (outside of weblogic) everything works fine. But when the application tries to go via weblogic I am able to run the Statement objects successfully but when I try to run PreparedStatements I get the following error:
    java.sql.SQLException: Statement cache size has not been set
    at weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:108)
    at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:138)
    at weblogic.jdbc.rmi.internal.ConnectionImpl_weblogic_jdbc_wrapper_PoolConnection_oracle_jdbc_driver_OracleConnection_812_WLStub.prepareStatement(Unknown Source)
    i have checked the StatementCacheSize and it is 10. Is there any other setting that needs to be implemented for this to work? Has anybody seen this error before? Any help will be greatly appreciated.
    Thanks.

    Pooja Bamba wrote:
    I just noticed that I did not copy the jdbc log fully earlier. Here is the log:
    JDBC log stream started at Thu Jun 02 14:57:56 EDT 2005
    DriverManager.initialize: jdbc.drivers = null
    JDBC DriverManager initialized
    registerDriver: driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    DriverManager.getDriver("jdbc:oracle:oci:@devatl")
    trying driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    getDriver returning driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    Oracle Jdbc tracing is not avaliable in a non-debug zip/jar file
    DriverManager.getDriver("jdbc:oracle:oci:@devatl")
    trying driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    getDriver returning driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    DriverManager.getDriver("jdbc:oracle:oci:@devatl")
    trying driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    getDriver returning driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    DriverManager.getDriver("jdbc:oracle:oci:@devatl")
    trying driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    getDriver returning driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    DriverManager.getDriver("jdbc:oracle:oci:@devatl")
    trying driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    getDriver returning driver[className=oracle.jdbc.driver.OracleDriver,oracle.jdbc.driver.OracleDriver@12e0e2f]
    registerDriver: driver[className=weblogic.jdbc.jts.Driver,weblogic.jdbc.jts.Driver@c0a150]
    registerDriver: driver[className=weblogic.jdbc.pool.Driver,weblogic.jdbc.pool.Driver@17dff15]
    SQLException: SQLState(null) vendor code(17095)
    java.sql.SQLException: Statement cache size has not been set
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269)Hi. Ok. This is an Oracle driver bug/problem. Please show me the pool's definition
    in the config.xml file. I'll bet you're defining the pool in an unusual way. Typically
    we don't want any driver-level pooling to be involved. It is superfluous to the functionality
    we provide, and can also conflict.
    Joe
         at oracle.jdbc.driver.OracleConnection.prepareCallWithKey(OracleConnection.java:1037)
         at weblogic.jdbc.wrapper.PoolConnection_oracle_jdbc_driver_OracleConnection.prepareCallWithKey(Unknown Source)
         at weblogic.jdbc.rmi.internal.ConnectionImpl_weblogic_jdbc_wrapper_PoolConnection_oracle_jdbc_driver_OracleConnection.prepareCallWithKey(Unknown Source)
         at weblogic.jdbc.rmi.internal.ConnectionImpl_weblogic_jdbc_wrapper_PoolConnection_oracle_jdbc_driver_OracleConnection_WLSkel.invoke(Unknown Source)
         at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
         at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
         at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
         at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
    SQLException: SQLState(null) vendor code(17095)

  • (statement cache size = 0) == clear statement cache ?

    Hi
    I ran this test with WLS 8.1. I set to the cache size to 5, and I call a servlet
    which invokes a stored procedure to get the statement cached. I then recompile
    the proc, set the statement cache size to 0 and re-execute the servlet.
    The result is:
    java.sql.SQLException: ORA-04068: existing state of packages has been discarded
    ORA-04061: existing state of package "CCDB_APPS.MSSG_PROCS" has been invalidated
    ORA-04065: not executed, altered or dropped package "CCDB_APPS.MSSG_PROCS"
    ORA-06508: PL/SQL: could not find program unit being called
    ORA-06512: at line 1
    which seems to suggest even though the cache size has set to 0, previously cached
    statements are not cleared.
    Rgs
    Erik

    Galen Boyer wrote:
    On Fri, 05 Dec 2003, [email protected] wrote:
    Galen Boyer wrote:
    On 14 Nov 2003, [email protected] wrote:
    Hi
    I ran this test with WLS 8.1. I set to the cache size to 5,
    and I call a servlet which invokes a stored procedure to get
    the statement cached. I then recompile the proc, set the
    statement cache size to 0 and re-execute the servlet.
    The result is:
    java.sql.SQLException: ORA-04068: existing state of packages
    has been discarded ORA-04061: existing state of package
    "CCDB_APPS.MSSG_PROCS" has been invalidated
    ORA-04065: not executed, altered or dropped package
    "CCDB_APPS.MSSG_PROCS" ORA-06508: PL/SQL: could not find
    program unit being called ORA-06512: at line 1
    which seems to suggest even though the cache size has set to
    0, previously cached statements are not cleared.This is actually an Oracle message. Do the following test.
    Open two sqlplus sessions. In one, execute the package.
    Then, in the other, drop and recreate that package. Then, go
    to the previous window and execute that same package. You
    will get that error. Now, in that same sqlplus session,
    execute that same line one more time and it goes through. In
    short, in your above test, execute your servlet twice and I
    bet on the second execution you have no issue.Hi. We did some testing offline, and verified that even a
    standalone java program: 1 - making and executing a prepared
    statement (calling the procedure), 2 - waiting while the
    procedure gets recompiled, 3 - re-executing the prepared
    statement gets the exception, BUT ALSO, 4 - closing the
    statement after the failure, and making a new identical
    statement, and executing it will also get the exception! JoeI just had the chance to test this within weblogic and not just
    sqlplus.Note, I wasn't using SQL-PLUS, I wrote a standalone program
    using Oracle's driver...
    MY SCENARIO:
    I had one connection only in my pool. I executed a package.
    Then, went into the database and recompiled that package. Next
    execution from app found this error. I then subsequently
    executed the same package from the app and it was successful.And this was with the cache turned off, correct?
    What the application needs to do is catch that error and within
    the same connection, resubmit the execution request. All
    connections within the pool will get invalidated for that
    package's execution.Have you tried this? Did you try to re-use the statement you had,
    or did you make a new one?
    Maybe Weblogic could understand this and behave this way for
    Oracle connections?It's not likely that we will be intercepting all exceptions
    coming from a DBMS driver to find out whether it's a particular
    failure, and then know that we can/must clear the statement cache.
    Note also that even if we did, as I described, the test program I
    ran did try to make a new statement to replace the one that
    failed, and the new statement also failed.
    In your case, you don't even have a cache. Would you verify
    in your code, what sort of inline retry works for you?
    Joe

  • Statement cache size - application changes withouth restart

    Hi, I would like to ask, how can I disable statement cache withouth restart.
    If I set statement cache size to "0" and push button "Apply chanes", I got
    message "No restart are necessary". Does it mean, that statement cache is
    flushed? There is production environment and I would like to make sure
    about it.
    Thank you in advance.
    Vladislav Rames, WLS 10.3.4

    Yes, setting the statement cache size is dynamic. A running server will close all cached
    statements and do no more caching, as soon as you set the cache size to zero.

  • Statement Cache Size

    hi,
    can anyone tell me what is statement cache size?? i am using oracle 11g release 2 and i receive the following error frequently in my alert log.
    ORA-03137: TTC protocol internal error : [12333] [10] [84] [101] [] [] [] []
    i read an article in which they have told that if statement cache size value is non-zero change it to zero. Is that the solution for this problem?? where can i see the value of statement cache size??

    Hi,
    You can refe to the below ORacle Doc
    http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jdbc_admin/jdbc_datasources.html
    Statement Cache Type—The algorithm that determines which statements to store in the statement cache. See Statement Cache Algorithms.
    Statement Cache Size—The number of statements to store in the cache for each connection. The default value is 10. See Statement Cache Size. http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/jdbc30/StmtCacheSample/Readme.html
    HTH
    - Pavan Kumar N

  • Unable to set Oracle driver statement cache size to 300

    Hi Friends,
    when i am starting thread pool worker using threadpoolworker using threadpoolworker.cmd i am getting the error as follows
    The root LoggedException was: Unable to set Oracle driver statement cache size to 300
    at com.splwg.shared.common.LoggedException.raised(LoggedException.java:65)
    at com.splwg.base.support.sql.OracleFunctionReplacer.setOracleCacheSize(OracleFunctionReplacer.java:232)
    at com.splwg.base.support.sql.OracleFunctionReplacer.initializeConnectionForNewSession(OracleFunctionReplacer.java:207)
    at com.splwg.base.support.context.FrameworkSession.initialize(FrameworkSession.java:225)
    at com.splwg.base.support.context.FrameworkSession.<init>(FrameworkSession.java:194)
    at com.splwg.base.support.context.ApplicationContext.createSession(ApplicationContext.java:417)
    at com.splwg.base.support.context.ApplicationContext.createThreadBoundSession(ApplicationContext.java:461)
    at com.splwg.base.support.context.SessionExecutable.doInReadOnlySession(SessionExecutable.java:96)
    at com.splwg.base.support.context.SessionExecutable.doInReadOnlySession(SessionExecutable.java:79)
    at com.splwg.base.support.context.ApplicationContext.initialize(ApplicationContext.java:211)
    at com.splwg.base.support.context.ContextFactory.buildContext(ContextFactory.java:114)
    at com.splwg.base.support.context.ContextFactory.buildContext(ContextFactory.java:90)
    at com.splwg.base.support.context.ContextFactory.createDefaultContext(ContextFactory.java:498)
    at com.splwg.base.api.batch.StandaloneExecuter.setupContext(StandaloneExecuter.java:258)
    at com.splwg.base.api.batch.StandaloneExecuter.run(StandaloneExecuter.java:129)
    at com.splwg.base.api.batch.StandaloneExecuter.main(StandaloneExecuter.java:357)
    at com.splwg.base.api.batch.AbstractStandaloneRunner.invokeStandaloneExecuter(AbstractStandaloneRunner.java:403)
    at com.splwg.base.api.batch.AbstractStandaloneRunner.run(AbstractStandaloneRunner.java:134)
    at com.splwg.base.api.batch.ThreadPoolWorker.run(ThreadPoolWorker.java:24)
    at com.splwg.base.api.batch.ThreadPoolWorker.main(ThreadPoolWorker.java:17)
    can any one tell me the exact error
    shyam.

    Hi Friends,
    when i am starting thread pool worker using threadpoolworker using threadpoolworker.cmd i am getting the error as follows
    The root LoggedException was: Unable to set Oracle driver statement cache size to 300
    at com.splwg.shared.common.LoggedException.raised(LoggedException.java:65)
    at com.splwg.base.support.sql.OracleFunctionReplacer.setOracleCacheSize(OracleFunctionReplacer.java:232)
    at com.splwg.base.support.sql.OracleFunctionReplacer.initializeConnectionForNewSession(OracleFunctionReplacer.java:207)
    at com.splwg.base.support.context.FrameworkSession.initialize(FrameworkSession.java:225)
    at com.splwg.base.support.context.FrameworkSession.<init>(FrameworkSession.java:194)
    at com.splwg.base.support.context.ApplicationContext.createSession(ApplicationContext.java:417)
    at com.splwg.base.support.context.ApplicationContext.createThreadBoundSession(ApplicationContext.java:461)
    at com.splwg.base.support.context.SessionExecutable.doInReadOnlySession(SessionExecutable.java:96)
    at com.splwg.base.support.context.SessionExecutable.doInReadOnlySession(SessionExecutable.java:79)
    at com.splwg.base.support.context.ApplicationContext.initialize(ApplicationContext.java:211)
    at com.splwg.base.support.context.ContextFactory.buildContext(ContextFactory.java:114)
    at com.splwg.base.support.context.ContextFactory.buildContext(ContextFactory.java:90)
    at com.splwg.base.support.context.ContextFactory.createDefaultContext(ContextFactory.java:498)
    at com.splwg.base.api.batch.StandaloneExecuter.setupContext(StandaloneExecuter.java:258)
    at com.splwg.base.api.batch.StandaloneExecuter.run(StandaloneExecuter.java:129)
    at com.splwg.base.api.batch.StandaloneExecuter.main(StandaloneExecuter.java:357)
    at com.splwg.base.api.batch.AbstractStandaloneRunner.invokeStandaloneExecuter(AbstractStandaloneRunner.java:403)
    at com.splwg.base.api.batch.AbstractStandaloneRunner.run(AbstractStandaloneRunner.java:134)
    at com.splwg.base.api.batch.ThreadPoolWorker.run(ThreadPoolWorker.java:24)
    at com.splwg.base.api.batch.ThreadPoolWorker.main(ThreadPoolWorker.java:17)
    can any one tell me the exact error
    shyam.

  • Jboss getting SQLException: Closed Statement prepared-statement- cache-size

    My first post in this forum , hope to get a quick resolution :)
    I am using Jboss 4.0.0 on Oracle 9.2.0.4.0
    In order to improve the app performance , I had specified prepared-statement-cache-size as 50 as follows ,
    <datasources>
    <local-tx-datasource>
    <jndi-name>jdbc/sct</jndi-name> <connection-url>jdbc:oracle:thin:@confidential:1560:sct1</connection-url>
    <user-name>Confidential</user-name>
    <password>Confidential</password>
    <min-pool-size>10</min-pool-size>
    <max-pool-size>120</max-pool-size>     <prepared-statement-cache-size>50</prepared-statement-cache-size>
    <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptio nSorter</exception-sorter-class-name>
    <idle-timeout-minutes>5</idle-timeout-minutes>
    <track-statements>true</track-statements>
    <new-connection-sql>select sysdate from dual</new-connection-sql>
    <check-valid-connection-sql>select sysdate from dual</check-valid-connection-sql>
    </local-tx-datasource>
    </datasources>
    After doing this , I start getting the following exception ,
    java.sql.SQLException: Closed Statement
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:180)
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:222)
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:285)
         at oracle.jdbc.driver.OracleStatement.ensureOpen(OracleStatement.java:5681)
         at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.j ava:409)
         at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.ja va:366)
         at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeQuery(CachedPrepare dStatement.java:57)
         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPrepa redStatement.java:296)
         at com.ge.sct.SiteText.getSiteTextFromDB(SiteText.java:292)
    Thanks in Advance
    Bhavin

    Hello,
    I am also facing the same error: somewhere just now I read,
    We were getting this error on JBoss / Oracle. The fix was setting the following to 0 in oracle-ds.xml:
    <prepared-statement-cache-size>0</prepared-statement-cache-size>
    Ref: http://www.jpox.org/servlet/forum/viewthread?thread=1108
    May be you can try this, I am also still finding the solution, I will try the above and let u know, if i get success.
    Regards,
    Rajesh

  • How to use Oracle statement cache?

    hi,
    I'm using weblogic 7 with the included Oracle JDBC Thin driver
    (9.2.0).
    One new(?) feature in this driver statement caching, but it seems that
    weblogic does not support this feature.
    Mainly the classes in weblogic.jdbc.vendor.oracle.* that are some sort
    of wrapper(?) to the thin driver does not support the methods that
    enable this.
    The driver docs says to use
    OracleConnection.setImplicitStatementCachingEnabled(true)
    or
    OracleConnection.setExplicitStatementCachingEnabled(true)
    but these just don't exist in the
    weblogic.jdbc.vendor.oracle.OracleConnection class.
    So, is this feature not supported by weblogic or there's another way
    of doing statement caching?
    Thanks
    anat

    anat wrote:
    hi,
    I'm using weblogic 7 with the included Oracle JDBC Thin driver
    (9.2.0).
    One new(?) feature in this driver statement caching, but it seems that
    weblogic does not support this feature.
    Mainly the classes in weblogic.jdbc.vendor.oracle.* that are some sort
    of wrapper(?) to the thin driver does not support the methods that
    enable this.You are correct. Our oracle interface doesn't have that call, so you can't enable it.
    Our next major release (in beta now) will allow you do do anything the driver
    provides. For now, we do provide the same sort of functionality in our pool.
    If you set the pool's statement cache size to N, then we will cache up to N
    prepared statements for each pooled connection. This will get you exactly the
    same performance benefit.
    Joe
    >
    >
    The driver docs says to use
    OracleConnection.setImplicitStatementCachingEnabled(true)
    or
    OracleConnection.setExplicitStatementCachingEnabled(true)
    but these just don't exist in the
    weblogic.jdbc.vendor.oracle.OracleConnection class.
    So, is this feature not supported by weblogic or there's another way
    of doing statement caching?
    Thanks
    anat

  • Corruption of statement cache

    I'm working on an application that uses stored procedures, and our statement cache size is set to 10. We are running the application on WLS 9.1 and using Microsoft's SQL Server 2005 XA driver. Most of the time, our application functions correctly. However, we are seeing a serious problem that occurs completely at random, but seems to always begin in conjunction with a redeployment when it does happen.
    The point in our system where we are able to identify it is a call to a stored procedure where the application specifically catches a primary key violation exception and performs some logging logic when this occurs (some PK violations are expected in this particular case, so it's not typically a true error situation). In our logs, it appears that this error is being caught and handled, when in fact no call to the stored procedure was ever sent to the database. If our DBAs enable tracing on SQL Server and we force a transaction through that we know will NOT throw a PK violation, they see no evidence that any transaction was ever begun or that any call was ever sent to the stored procedure, but our application is somehow catching this exception. It's as if the application is receiving cached results from a previous call to the stored procedure, and the call to the DB is never being executed.
    If we clear the statement cache or restart WLS, the problem disappears until the next time it randomly resurfaces. We cannot seem to force it to happen. This is a tremendous problem because in a normal production environment we would not be specifically monitoring this situation and thus would have no knowledge that transactions are being dropped. Is this a known bug, and if so, has it been fixed in WLS 9.2? Any help would be greatly appreciated.
    Regards,
    Sabrina

    We started off using Microsoft's driver because at the time, SQL Server 2005 was brand new and there was no support for it in WLS. In light of all the problems we've had with it, we may consider using BEA's driver now that it is available.
    We have been in touch with Microsoft on numerous occasions regarding the driver issues we have seen, and by this point most (that we know of) seem to have been fixed. However, there is one nagging issue that we can't seem to resolve and I'm not even sure whether this one is a Microsoft issue or something that we have configured incorrectly in WLS. It appears that whenever an XA transaction is rolled back by the container, the error below appears in the WLS server log. Based on what I have seen in checking a handful of specific transactions, this error does not appear to be causing any actual data integrity issues; the transactions seem to be successfully rolled back and reprocessed if necessary. However, we have so much data coming into our system that it is difficult to tell. In one area of the system in particular, we have a lot of DB deadlocking issues and we're not sure whether that is related to this problem. Have you seen this error before? Thanks again for your help.
    Regards,
    Sabrina
    ####<Jul 24, 2006 7:03:33 AM EDT> <Error> <JTA> <ASAP-WEBLOGIC1> <wls_ManagedServer_1> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-1E9A446DF85749F80F90> <> <1153739013725> <BEA-110412> <Xid=BEA1-1E9A446DF85749F80F90(21643353),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3,seconds left=30,activeThread=Thread[[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads],XAServerResourceInfo[WLStore_domain_filestore]=(ServerResourceInfo[WLStore_domain_filestore]=(state=rolledback,assigned=wls_ManagedServer_1),xar=WLStore_domain_filestore3792941,re-Registered = false),XAServerResourceInfo[IngestorXADataSource]=(ServerResourceInfo[IngestorXADataSource]=(state=rolledback,assigned=wls_ManagedServer_1),xar=IngestorXADataSource,re-Registered = false),SCInfo[test_domain+wls_ManagedServer_1]=(state=rolledback),properties=({}),local properties=({weblogic.jdbc.jta.IngestorXADataSource=[ No XAConnection is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_ManagedServer_1+asap-weblogic1:8010+test_domain+t3+, XAResources={WLStore_domain_filestore, ErrorXADataSource, IngestorXADataSource},NonXAResources={})],CoordinatorURL=wls_ManagedServer_1+asap-weblogic1:8010+test_domain+t3+) completed heuristically: (IngestorXADataSource, HeuristicHazard, (javax.transaction.xa.XAException: java.sql.SQLException: ROLLBACK:Status:0 msg:*** SQLJDBC_XA DTC_ERROR Context: xa_rollback, state=1, StatusCode:-4 (0xFFFFFFFC) ***)) >
    ####<Jul 24, 2006 7:03:33 AM EDT> <Notice> <EJB> <ASAP-WEBLOGIC1> <wls_ManagedServer_1> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1153739013725> <BEA-010017> <Exception occurred during rollback of transaction Xid=BEA1-1E9A446DF85749F80F90(21643353),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3,seconds left=30,XAServerResourceInfo[WLStore_domain_filestore]=(ServerResourceInfo[WLStore_domain_filestore]=(state=rolledback,assigned=wls_ManagedServer_1),xar=WLStore_domain_filestore3792941,re-Registered = false),XAServerResourceInfo[IngestorXADataSource]=(ServerResourceInfo[IngestorXADataSource]=(state=rolledback,assigned=wls_ManagedServer_1),xar=IngestorXADataSource,re-Registered = false),SCInfo[test_domain+wls_ManagedServer_1]=(state=rolledback),properties=({}),local properties=({weblogic.jdbc.jta.IngestorXADataSource=[ No XAConnection is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_ManagedServer_1+asap-weblogic1:8010+test_domain+t3+, XAResources={WLStore_domain_filestore, ErrorXADataSource, IngestorXADataSource},NonXAResources={})],CoordinatorURL=wls_ManagedServer_1+asap-weblogic1:8010+test_domain+t3+): javax.transaction.SystemException: Heuristic hazard: (IngestorXADataSource, HeuristicHazard, (javax.transaction.xa.XAException: java.sql.SQLException: ROLLBACK:Status:0 msg:*** SQLJDBC_XA DTC_ERROR Context: xa_rollback, state=1, StatusCode:-4 (0xFFFFFFFC) ***))
         at weblogic.transaction.internal.ServerTransactionImpl.internalRollback(ServerTransactionImpl.java:405)
         at weblogic.transaction.internal.ServerTransactionImpl.rollback(ServerTransactionImpl.java:371)
         at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:485)
         at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:332)
         at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:288)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:3824)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:3738)
         at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4228)
         at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)
    .>
    ####<Jul 24, 2006 7:03:33 AM EDT> <Info> <EJB> <ASAP-WEBLOGIC1> <wls_ManagedServer_1> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1153739013725> <BEA-010213> <Message-Driven EJB: IngestDBLoggerMDB's transaction was rolledback. The transaction details are: Xid=BEA1-1E9A446DF85749F80F90(21643353),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3,seconds left=30,XAServerResourceInfo[WLStore_domain_filestore]=(ServerResourceInfo[WLStore_domain_filestore]=(state=rolledback,assigned=wls_ManagedServer_1),xar=WLStore_domain_filestore3792941,re-Registered = false),XAServerResourceInfo[IngestorXADataSource]=(ServerResourceInfo[IngestorXADataSource]=(state=rolledback,assigned=wls_ManagedServer_1),xar=IngestorXADataSource,re-Registered = false),SCInfo[test_domain+wls_ManagedServer_1]=(state=rolledback),properties=({}),local properties=({weblogic.jdbc.jta.IngestorXADataSource=[ No XAConnection is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_ManagedServer_1+asap-weblogic1:8010+test_domain+t3+, XAResources={WLStore_domain_filestore, ErrorXADataSource, IngestorXADataSource},NonXAResources={})],CoordinatorURL=wls_ManagedServer_1+asap-weblogic1:8010+test_domain+t3+).>

  • Caching of Prepared and Callable Statements

    A Prepared Statement object represents a precompiled SQL statement.
    Where is this precompiled SQL statement stored, in the database?
    What happens when this object goes out of scope / garabage collected?
    Using the WebLogic App. Server's console, we can set the size and type of the Statement Cache. So does that mean even after the Prepared Statement object going out of scope, the precompiled SQL it had represented is still available in the database ?

    Read this thread
    http://forum.java.sun.com/thread.jspa?threadID=692297
    It will answer your queries and much more too. :)

  • High memory usage on JDBC 10.2.0.1.0 driver on Prepared/Callable Statements

    We are observing high memory usage for each callable/prepared stmt, using 10.2.0.1.0 JDBC Driver. The char[] in oracle/jdbc/driver/T4CVarcharAccessor was alloted 64K to 320K and grows with usage. This problem is worse with 10.1.0.2. driver which was alloted 720K byte of memory for each stmt right at the start.
    We found this by doing a JVM heap dump and analyzing the heap dump using IBM's heap analyser. Here is a snapshot of the heap dump for this object:
    321,240 [216] 11 oracle/jdbc/driver/T4CVarcharAccessor 0x72752968
    - 320,616 [320,616] 0 char[] 0x72761028
    - 216 [216] 0 short[] 0x727527d8
    - 72 [32] 1 java/lang/String 0x727530a0
    - 24 [24] 0 int[] 0x72752938
    - 24 [24] 0 int[] 0x72752948
    - 24 [24] 0 int[] 0x72752958
    - 16 [16] 0 bool[] 0x72752928
    - 16 [16] 0 byte[] 0x727528b0
    - 16 [16] 0 bool[] 0x72752918
    - 10,336 [88] 15 oracle/jdbc/driver/T4CMAREngine 0x712e7128
    - 1,544 [1,032] 79 oracle/jdbc/driver/T4CPreparedStatement 0x72754c58
    It is repeated many times for each prepared/callable stmt call.
    Details of our platform is:
    Database - Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
    JDBC Driver - Oracle Database 10g Release 2 (10.2.0.1.0) JDBC Drivers
    JDK - [Classic VM, Version 1.4.2] from [IBM Corporation]
    Our callable stmts are not using any of the Oracle caching facility. It is a simple call stmt with OUT parameters and the stmt is closed after each execution. However, we implement our own connection pooling and do not close the connection after each stmt.
    Is there a workaround to this? Would appreciate any feedback.

    What is happening is that each new CallableStatement you create allocates a new char[]. I would strongly encourage you to use the implicit statement cache if at all possible. That way instead of creating a new statement each time with a new char[] you will get an already existing statement and reuse the existing char[]. Closing a statement releases the char[] so if you really are closing the statements the char[]s should be GC'd.
    Douglas

  • Callable Statement wot working properly

    I have a situation where using CallableStatement only executes the stored proc intermittenly,
    while utilizing Statement works all the time. This didn't happen under WLS 5.1 SP
    6. Does anyone else have the same problems.
    Also in both cases the jdbc log produces the following message:
    SQLWarning: reason(010P4: An output parameter was received and ignored.) SQLState(010P4)
    But we have nothing being returned from the stored proc and no OUT parameters.
    We are using Jconnect native jdbc drivers with Sybase 11.9.2
    Thanks a lot, Alex

    Lev wrote:
    We are using WebLogic 7.0 and we downloaded the latest version
    of Sybase Driver. Previously we used WebLogic 5.1 sp 9 and
    excatly the same sybase driver and code and it worked.Yes. The change in our code is that we now cache PreparedStatements
    with their pooled connections, and when a pool connection is re-used,
    if the requestor prepares a statement with the same parameters including the SQL,
    as before, they get a cached statement which has had it's prior arguments cleared.
    This is a big performance win, but it has had the side effect of revealing bugs
    in various JDBC drivers when statements are re-used for an indefinite period
    of time.
    As I said, the first thing to do is to stop the symptoms, byt setting the cache size
    to 0, to stop us caching. If you are willing to help us debug the driver, the test would
    be a standlaone program that used the sybase driver to make a connection and
    prepare a statement like your code uses, then run a long-running loop that
    sets the arguments, executes the statement, calls clearParameters(), and repeats.
    This duplicates what we make the driver do, and should eventually demonstrate
    the driver bug. Is there any chance that the same prepared statement is being
    used in different ways, such that the same SQL is used for a CallableStatement
    getting back output parameters (even just the procedure status) sometimes, and
    as a PreparedStatement other times?
    Joe
    >
    >
    Joseph Weinstein <[email protected]> wrote:
    Alex wrote:
    Joeseph,
    We had jconn2.jar in front of weblogic classpath all the time
    and it does not help.make sure it's the latest.
    We are about to open a case with WebLogic.
    Could you please help us ASAP.Understood. What version of the server are you running now? The first
    step is to avoid the sybase driver problem by turning off our statement
    cache.
    Thanks, Alex
    Joseph Weinstein <[email protected]> wrote:
    >
    Hi. This probably has to do with our caching of prepared statements and
    a bug in the version of the sybase driver that we ship. Please download
    sybase's latest driver and put it ahead of all weblogic stuff in the
    server
    classpath, and let me know...
    Joe
    "Alex" <[email protected]> wrote in message
    news:[email protected]...
    I have a situation where using CallableStatement only executes the
    stored
    proc intermittenly,
    while utilizing Statement works all the time. This didn't happen
    under
    WLS
    5.1 SP
    6. Does anyone else have the same problems.
    Also in both cases the jdbc log produces the following message:
    SQLWarning: reason(010P4: An output parameter was received and ignored.)SQLState(010P4)
    But we have nothing being returned from the stored proc and no OUTparameters.
    We are using Jconnect native jdbc drivers with Sybase 11.9.2
    Thanks a lot, Alex

  • New FAQ Entry on JVM Parameters for Large Cache Sizes

    I've posted a new [FAQ entry|http://www.oracle.com/technology/products/berkeley-db/faq/je_faq.html#60] on JVM parameters for large cache sizes. The text of it is as follows:
    What JVM parameters should I consider when tuning an application with a large cache size?
    If your application has a large cache size, tuning the Java GC may be necessary. You will almost certainly be using a 64b JVM (i.e. -d64), the -server option, and setting your heap and stack sizes with -Xmx and -Xms. Be sure that you don't set the cache size too close to the heap size so that your application has plenty of room for its data and to avoided excessive full GC's. We have found that the Concurrent Mark Sweep GC is generally the best in this environment since it yields more predictable GC results. This can be enabled with -XX:+UseConcMarkSweepGC.
    Best practices dictates that you disable System.gc() calls with -XX:-DisableExplicitGC.
    Other JVM options which may prove useful are -XX:NewSize (start with 512m or 1024m as a value), -XX:MaxNewSize (try 1024m as a value), and -XX:CMSInitiatingOccupancyFraction=55. NewSize is typically tuned in relationship to the overall heap size so if you specify this parameter you will also need to provide a -Xmx value. A convenient way of specifying this in relative terms is to use -XX:NewRatio. The values we've suggested are only starting points. The actual values will vary depending on the runtime characteristics of the application.
    You may also want to refer to the following articles:
    * Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning
    * The most complete list of -XX options for Java 6 JVM
    * My Favorite Hotspot JVM Flags
    Edited by: Charles Lamb on Oct 22, 2009 9:13 AM

    First of all please be aware HSODBC V10 has been desupported and DG4ODBC should be used instead.
    The root cause the problem you describe could be related to a timeout of the ODBC driver (especially while taking care of the comment: it happens only for larger tables):
    (0) [MySQL][ODBC 3.51 Driver]MySQL server has gone away (SQL State: S1T00; SQL
    (0) Code: 2006)
    indicates the Driver or the DB abends the connection due to a timeout.
    Check out the wait_timeout mysql variable on the server and increase it.

  • Proxy 4 - Cache size keeps growing

    I may have a wrong cache setting somewhere, but I can't find it. I am running Proxy 4.0.2 (for windows).
    Under Cache settings, I have "Cache Size" set to 800MB. Under "Cache Capacity" I have it set to 1GB (500 MB-2GB).
    The problem is my physical cache size on the hard drive keeps growing and growing and is starting to fill the partition on the hard drive. At last count, the "cache" directory on the hard drive which holds the cache files is now using 5.7GB of space and still growing.
    Am I mis-understanding something? I thought the max physical size would be a lot lower, and stop at a given size. But the cache directory on the hard drive is now close to 6GB and still growing day by day. When is it going to stop growing, or how do I stop it and put a cap on the physical size it can grow to on the hard drive?
    Thanks

    Until 4.03 is out, you can use this script..
    Warning: experimental, run this on a copy of cache first to make sure that it works as you want it.
    The firs argument is the size in MB's that you want to remove.
    I assume your cachedir is "./cache" if it is not, then change the variable $cachedir to
    the correct value.
    ==============cut-here==========
    #!/bin/perl
    use strict;
    use File::stat;
    my $cachedir = "./cache";
    my $gc_size; #bytes
    my $verbose = 0;
    sub gc_file {
        my $file = shift;
        my $sb = stat($file);
        $gc_size -= $sb->size;
        unlink $file;
        print "$gc_size more after $file\n" if $verbose;
        exit 0 if $gc_size < 0;
    sub main {
        my $size = shift;
        $gc_size = $size * 1024 * 1024; #in MB's
        opendir(DIR, $cachedir) || die "can't opendir $cachedir: $!";
        my @sects = grep {/^s[0-9]\.[0-9]{2}$/} readdir(DIR);
        closedir DIR;
        foreach my $sect (@sects) {
            chomp $sect;
            opendir (CDIR, "$cachedir/$sect") || die "cant opendir $cachedir/$sect: $!";
            my @ssects = grep {/^[A-F0-9]{2}$/} readdir(CDIR);
            closedir CDIR;
            foreach my $ssect (@ssects) {
                chomp $ssect;
                opendir (SCDIR, "$cachedir/$sect/$ssect") || die "cant opendir $cachedir/$sect/$ssect: $!";
                my @files = grep {/^[A-Z0-9]{16}$/} readdir(SCDIR);
                closedir SCDIR;
                foreach my $file (@files) {
                    gc_file "$cachedir/$sect/$ssect/$file";
    main $ARGV[0] if $ARGV[0];
    =============cut-end==========On your second problem, the easiest way to recover a corrupted partition is to list out the sections in that partition, and delete those sections that seem like odd ones
    eg:
    $ls ./cache
    s4.00 s4.01 s4.02 s4.03 s4.04 s4.05 s4.06 s4.07 s4.08 s4.09 s4.10 s4.11 s4.12 s4.13 s4.14 s4.15 s0.00
    Here the s0.00 is the odd one out, so remove the s0.00 section. Also keep an eye on the relative sizes of the sections. if the section to be removed is larger than the rest of the sections combinde, you might not want to remove that.
    WARNING: anything you do, do on a copy

  • Is there a difference between Statement Cache and the statement handle!

    Hello!
    The OCI statement cache is !session! wide. When I have a sql statement that was used before, I can use this feature.
    But what is the difference between this feature and my statement handle for a certain sql statement that I can store and reuse a second time?
    My stored statement handle is already prepared and the placeholders are bound. The second time I only have to copy new values in the memory positions and do an execute and that's all.
    Thank you in advance
    Wolfgang

    The underlying optimization is the same. When you re-execute a statement, you are reusing the metadata already available in the statement and the cursor already open on the server. If you know exactly the set of statements that you are going to execute repeatedly, you can maintain the cache on your own. (Yes, you save on doing the Bind/Define calls multiple times).
    OCI Statement cache makes it transparent and the application does not need to keep the references/indexes to the relevant statements. Also once a cache size is set, least recently used statements get out of the cache when the cache is full and needs to accommodate more.
    To optimize the bind/defines on the statements from the statement cache, you can use this feature:
    http://www.filibeto.org/sun/lib/nonsun/oracle/11.2.0.1.0/E11882_01/appdev.112/e10646/oci09adv.htm#sthref1358

Maybe you are looking for

  • Variavel de sistema no Crystal

    Como utilizo um campo variavel do sistema do SAP para o crystal Exemplo o campo de centro de Lucro numa Nota Fiscal de entrada. Estou fazendo um resumo da nota com todas retenções e impostos fretes e etc no crystal

  • How to access Excel PROTECTED spreadsheet in SharePoint Web Access Web Part in SharePoint2013?

    I have excel file which is protected by password. I need to access Sheet 1 on SharePoint Web Part Page on Dashboard. While I add protected I can not able to Excel Sheet is corrupted as per below image.! While I add simple Excel Spreadsheet, it works

  • Change the valuation class of material [Stock transport order scenario]

    Dears, Client would like to change the valuation class of material. There is no open Purchase order/Process order/Purchase requistion and stock in plant. Scenario- One Stock transport order is created. For same goods issue (351-issuing plant) and goo

  • IWeb Gallery and MobileMeGalleries - what's the difference?

    What is the difference between these? So I have two sites gallery.me.com/[YourMemberName]and web.me.com/[YourMemberName]; can they be combined somehow? This is kinda confusing. So far I find iWeb to less than intuitive and designed poorly. Not the ty

  • Do Time Machine backups carry across the OSX?

    Basically, I had a computer with Mavericks and the hard drive went crazy and I had to reinstall the OSX, yet the only thing I had around was a copy of Lion. So, what I'd like to know is if my Time Machine backup will also install Mavericks on top of