Statement cache bug in OracleConnectionCacheImpl

Hi,
Did you guys ever try setStmtCacheSize() in OracleConnectionCacheImpl? When I enable statement cache in connection cache, I always get "close connection error". It seems connection.close() did not clean up the statement associating with this conneciton.
This is my code piece:
//occ is object of OracleConnectionCacheImpl
Conection conn1 = occ.getConnection();
doSomeDBWork(conn1);
conn1.close();
Connection conn2 = occ.getConnection();
doSomeDBWork(conn2); <-- SQLException
Thank you
Jason

I found out the problem. The JDBC team should set the stmtCacheSize 0 before reusePooledConnection. This is the only way we can do without phsically close the connection.

Similar Messages

  • Bug with binding / statement cache?

    And the next trouble... :(
    When Sql on two different OracleCommand's is equals, but parameter types differs, exceptions raised.
    Two different exception raised, depends of AddToStatementCache property, on call ExecuteReader or on call Read().
    Test case:
                OracleConnectionStringBuilder csb = new OracleConnectionStringBuilder();
                csb.UserID = "xxxxxx";
                csb.Password = "xxxxxxx";
                csb.DataSource = "xxxxxxxx";
                OracleConnection conn = new OracleConnection(csb.ToString());
                conn.Open();
                string sql = @"SELECT :v1 FROM DUAL";
                // Create first command
                OracleCommand cmd = conn.CreateCommand();
                cmd.BindByName = true;
                cmd.CommandText = sql;
                // Bind number parameter
                OracleParameter p1 = cmd.CreateParameter();
                p1.ParameterName = "v1";
                p1.Value = 1000.123m;
                cmd.Parameters.Add(p1);
                // Select number value
                OracleDataReader reader1 = cmd.ExecuteReader();
                reader1.Read();
                decimal d1 = reader1.GetDecimal(0);
                // dispose first reader and command
                reader1.Dispose();
                cmd.Dispose();
                // Create second command with equals Sql
                OracleCommand cmd2 = conn.CreateCommand();
                cmd2.BindByName = true;
                cmd2.CommandText = sql;
                // if uncomment next line, exception (1) changes to exception (2)
                cmd2.AddToStatementCache = false;
                // Bind string parameter
                OracleParameter p2 = cmd2.CreateParameter();
                p2.ParameterName = "v1";
                p2.Value = "sdf g sdfg sdfg sdfgsdf";
                cmd2.Parameters.Add(p2);
                // Select scalar string
                OracleDataReader reader2 = cmd2.ExecuteReader(); // Exception (1)! ORA-01475: must reparse cursor to change bind variable datatype
                reader2.Read();  // Exception (2)! ORA-01722: Invalid number
                string s2 = reader2.GetString(0); Well, few questions:
    * How i can force "reparse" cursor, if need???
    * Why statement cache dont use parameter signatures to distinguish statements with equals SQL and different parameter types??
    * Where i can post that bug (and some other) to quick answer from ODP.NET support? In this forum only? Anywhere else?
    Thanks.

    Hi,
    I tried your code, but get the 1722 every time, and dont seem to be able to get the 1475.
    I think the explanation here is that ODP uses the command text only in determining whether to pull the statement from the cache (ie, not the data types, as you've seen).
    With respect to your questions:
    1) I'd have thought con.PurgeStatementCache() would have done it, but that didnt work for me. I’ve tried Statement Cache Purge=true in the connect string, cmd.AddStatementToCache=false, and con.PurgeStatementCache(), but none of them make the code work. I'm guessing the statement is getting added to the cache every time even though we're doing our best not to, and that’s why the problem behavior. I'm looking into that further.
    2) I'd assume that development just didnt take this scenario into account. Typically the data type of a bind variable in any given statement wouldnt change.
    3) If you have an Oracle Support contract, just log a SR via Metalink (http://metalink.oracle.com)
    Cheers,
    Greg

  • 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)

  • 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+).>

  • Why is statement cache initialized for pool "null"

    We see the following entry upon startup:
    ####<16-May-2007 4:55:54 o'clock PM EDT> <Info> <JDBC> <ex-wl1> <prd_pt_1> <main> <<WLS Kernel>> <> <BEA-001072> <Connection for XA pool "cgPool" created.>
    ####<16-May-2007 4:55:54 o'clock PM EDT> <Info> <JDBC> <ex-wl1> <prd_pt_1> <main> <<WLS Kernel>> <> <BEA-001132> <Initialized statement cache of size "10" for connection in pool "null".>
    We are running WL8.1 SP4 on a Solaris platform.
    Thanks for any help.

    Andre Fischer wrote:
    We see the following entry upon startup:
    ####<16-May-2007 4:55:54 o'clock PM EDT> <Info> <JDBC> <ex-wl1> <prd_pt_1> <main> <<WLS Kernel>> <> <BEA-001072> <Connection for XA pool "cgPool" created.>
    ####<16-May-2007 4:55:54 o'clock PM EDT> <Info> <JDBC> <ex-wl1> <prd_pt_1> <main> <<WLS Kernel>> <> <BEA-001132> <Initialized statement cache of size "10" for connection in pool "null".>
    We are running WL8.1 SP4 on a Solaris platform.
    Thanks for any help.Hi. It's a harmless silly bug where the code building the statement cache
    starts before it actually has access to the name of the pool... ;)
    Joe

  • Statement caching and batch update

    Can these 2 JDBC features work together ?
    Is it possible while statement is cached to be reparsed (soft) if used in batch update ?
    I am asking this questions because i have a sitution where an insert is cached using implicit statement caching and then put in a batch to exeute batch updates !!! From statspack reports i find that 1/3 of statements are reparsed ... even soft !!!

    Statement caching and batch update work fine together. The most common cause of unexpected soft parses is changing the type of some parameters. If you first bind one type, setInt(1, ...), do addBatch, then bind another type to the same parameter, setString(1, ...), and do addBatch, you will get a soft reparse. There is nothing the JDBC driver can do about this, the RDBMS requires it.
    In general, whatever parse behavior you see with statement caching you would also see without it.
    Douglas

  • Can't believe the caching bug is STILL there

    Hi,
    I MUST be missing something. It can't be true that this has not been fixed after so many years.
    So well, the problem is, every time you load an external asset or file, say for example using a Loader object or a URLLoader object (the same happened in AS2 with MovieClipLoader, LoadVars, XML.load() etc etc, and even before with loadMovie, etc) - every time you load a file, the Flash Player caches that file, and this is independent from your browser: it is Flash Player's own (and primitive) caching mechanism.
    Whenever you load a file with the same URL again, no matter whether the file has been changed or not, Flash Player will use the cached copy, and there's NO WAY to prevent that - there are a few workaround that I will discuss later but they don't solve the problem completely, besides being terribly combersome.
    Now, the HTTP protocol has a wonderful mechanism to manage the caching of files in an intelligent way, which has been working for years and, I think, was invented even before flash existed, however at least 10 years ago, and it works fine.
    If an HTML page has an IMG tag with an image, for example, and if the browser has already a cached version of the image with that URL, the browser will first ask the server for that file and declare it has a cached version with date xxx; if the server's file is not newer than xxx, then the server replies that the file has not changed and the browser can use its cached version (or insist to redownload it if he wishes). But if the file on the server is newer, the server will reply with the new file, and the browser will NEVER show an obsolete cached version of the image (or whatever file).
    Now, I don't know why, Flash Player was designed in a very primitive way that ignores this whole mechanism provided and standardised by the HTTP protocol. Flash Player will ALWAYS use a cached version of the file if he has one, it won't worry about veryfying whether it is obsolete or not.
    So, unless the user clears its cache, whenever you update an xml, txt, jpg or whatever file that is loaded within your flash application, users that have previously visited the page may still see the old version.
    Now, there's an easy workaround for ensuring that a cached version of the file is NEVER used, which is appending a "?somerandomname="+n to the filename, where n is obtained for example as n=(new Date()).value(); in order to ensure that it is always different.
    This way, the complete url of the file is always different and the cached version will never be used.
    However, this is not a solution either. For small text files it is ok, but for images and swf's for example, you DO want the cached file to be used IF it is not obsolete. Otherwise, returning visitors will always have to wait for the complete download time of everything, including files that have been downloaded yesterday and have not been modified.
    So, this problem has been solved ages ago by the HTTP protocol, but the Flash Player is naive and ignores it.
    I used to use 2 workarounds: the one I have mentioned for small files (texts, xml's), and the following one for files that can be updated every once in a while:
    In the main html page, I append "?lastupdate=dddddd" to the swf name, where dddddd is a manually edited date of the last time something relevant has been updated. So for example:
    <object ....... etc etc> <param name="movie" value="mainswffile.swf?lastupdate=20090625"/>... <embed etc etc etc src="mainswffile.swf?lastupdate=20090625"/></object>
    Or something like that.
    When I update some of the files that are to be loaded, I manually edit the "lastupdate" thing in the html.
    Then in the ActionScript programming I use the _root.lastupdate variable to append to the filenames of images or assets I load.
    All this is horribly cumbersome and error-prone. Image you deploy a website to a client that will be able to update his own texts and images: you have either to explain him how to edit the html file also, or create some complicated server-side or client-side script to manage the cache-avoiding system. That is, reinventing the wheel, in this case the cache.
    Every time a new version of the player was released, I expected it to fix the stupid caching problem and to make my cumbersome tricks obsolete and unnecessary.
    I expected to see that the new version would make proper use of HTTP caching protocol specifications, and use cached files ONLY when they are not outdated, after verifying it with the server according to the HTTP protocol.
    Every new version of the player was a disappointment.
    Then I hope the new version of the language, Action Script 3.0, would fix this.
    No, it seems it doesn't.
    I've done some tests with AS3 and with my great and sad surprise, the caching "bug" is still there.
    Well, the bug, not the "bug": this is a bug proper, because there's no reason why it should work this way.
    So, my question is.
    Maybe am I missing something? Is there a way, by using some method or property of URLLoader, Loader and/or URLRequest, to tell Flash Player to use the cache in an intelligent way? I mean, in a not-astonishingly-stupid way?
    Note that I'm not talking about forcing it to NOT USE cache at all: I mean using a cached version when it is appropriate, and redownloading the file when needed, as all decent http application have done for years.
    Perhaps there IS a way to solve this.... It should be the default behaviour and should be transparent, but however, if there is a SERIOUS fix (not a hackaround), that would at least solve the problem.
    Do anybody know of a method that really works?
    (I have read of people trying by using http headers with caching directives but without success; or in the best case maybe they were able to force never-caching, which is NOT a solution as I explained)
    Thanks in advance.
    And if there is any Adobe developer listening, please fix this bug since it is really a shame that an application written in 2008 or 2009 suffers from a problem that was elegantly and definitely solved in the XX century.
    Regards,
    m.

    I wrote a long reply and when I posted it it vanished.
    I had even control+c'opied it before submitting but it didn't even get into my clipboard.
    Shame on this forum (sorry to say that, but that's what I have to say).
    So, I'll try to write it again but it won't be the same: the amount of rage is augmented.
    Thank you BWolfe for letting me know that Flash now (since last year) has a bug management system. It was also such an enormous shame that it didn't have one.
    Adobe used to confuse bug reports with feature requests; now this kind of confusion is still partially there and it is reflected by the voting thing, which is an absolute aberration. In a decent bug management system, the developers take the responsibility to give the bugs the priority they deserve; and no matter how low the priority, even the smallest bug ALWAYS get into the queue.
    Now this bug we are discussing has been well known for AT LEAST EIGHT YEARS and I am not exaggerating at all, as I started using flash in 2001 and the issue was already mentioned here and there in forums etc; probably some blind people didn't see it as a bug (rather as a situation you have to face or work around), but it was known. And the very solution, as I already pointed out, was there even before Flash was conceived (well, for the sake of scientifical rigour, I should say, before Flash was commercialized): the HTTP protocol has the capability to perfectly manage file caching in a manner transparent to the higher layer.
    So, since I don't believe that nobody at Adobe (formerly Macromedia) has heard about a bug that every intermediate-level actionscript developer in the world knows of, it is already kind of a shame that we have to report it in 2009, but that's ok. But that we have to get votes, no, that's an insult.
    Jesus, ActionScript is a programming language, man, A PROGRAMMING LANGUAGE... it is not like Photoshop or Premiere; and it seems like in so many years, people who manage it haven't yet realised it completely.
    Big Brother contestants should be voted. Feature requests may be voted. Bugs cannot be voted should just be fixed one by one as soon as possible.
    Well, sorry for the rant and thank you for the answers.
    Hope this gets through this time.

  • 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

  • Problems with statement cache using OCI

    Hello!
    We recently changed our program to use statement cache, but we found a problem and not yet a solution.
    We have problems in this situation:
    OCIEnvCreate();
    OCIHandleAlloc();
    OCILogon2(..... OCI_LOGON2_STMTCACHE);
    OCIStmtPrepare2("CREATE TABLE db_testeSP (cod_usuario INTEGER, usuario CHAR(20), dat_inclusao DATE)")
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    OCIStmtPrepare2("INSERT INTO db_testeSP (1,\'user\',CURRENT_DATE");
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    OCIStmtPrepare2("SELECT * FROM db_testeSP");
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    OCIStmtPrepare2("DROP TABLE db_testeSP");
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    OCIStmtPrepare2("CREATE TABLE db_testeSP (cod_usuario INTEGER, usuario CHAR(20), idade INTEGER, dat_inclusao DATE)");
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    OCIStmtPrepare2("INSERT INTO db_testeSP (1,\'user\',20,CURRENT_DATE");
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    OCIStmtPrepare2("SELECT * FROM db_testeSP");
    OCIStmtExecute();
    OCIStmtRelease(... OCI_DEFAULT);
    On the second Select (wich is in bold), returns -1 from Execute, and if I get the error with OCIErrorGet I have: ORA-00932 - inconsistent datatypes
    Researching I discovered that this is statement cache problem, is there a way to clear the cache of one table ? I'm asking this because I could clear whenever there is a DROP TABLE or ALTER TABLE instruction (but I don't know what statements will need to be cleared from the cache). I can't clear all the cache because I may have other statements from other tables on the cache.
    This situation above is just an example, but I think that this will cause other problems too.
    Our program is a gateway from the main program and database, so I don't know the SQL instructions before executing. How can we resolve this problem?
    I have tested this issue with Oracle 10g (10.2.0.4.0) and 11g (11.2.0.1.0) both 64 bits and the result is the same (the OCI is version 11.2.0).
    We appreciate any help.
    Thanks in advance,
    Daniel

    After long time searching for answers, apparently this is expected to happen and the program should not use Statement caching in this situation.
    I found this on an Oracle document (Tuning Data Source Connection Pools - 11g Release 1 (10.3.6)) and we will need to review the use of statement caching.
    Stay as a tip for others who might be in the same situation.

  • Prepared statement cache & Oracle

    Hi -
    Does Weblogic's prepared statement caching only work when using their
    type-2 Oracle driver? Are there any documents about using this
    Weblogic feature? I have only found small references in the Weblogic
    documentation so far -- nothing with much detail.
    Thanks for any help,
    - Mark

    "Joseph Weinstein" <[email protected]> wrote in message
    news:[email protected]..
    >
    >
    Mark Cassidy wrote:
    Hi -
    Does Weblogic's prepared statement caching only work when using their
    type-2 Oracle driver?No. It is generic to JDBC. Any JDBC driver should allow re-use ofPreparedStatements,
    and our pool will cache for any driver.
    Are there any documents about using this
    Weblogic feature? I have only found small references in the Weblogic
    documentation so far -- nothing with much detail.You are correct that there is too little documentation at this time.
    Thanks for any help,
    - Mark
    Thanks Joe!
    Do you know if each connection's cache is FIFO? Or do you use
    least-recently-used algorithm?
    I found one comment you made regarding XA pools. That means that if we are
    doing 2-phase commit processing that some of these benefits could erode? I
    didn't understand why. If we assume that the connections in a given pool
    after a time get a good sampling of popular prepared statements, would their
    being XA or not matter? Maybe I missed your point entirely.
    - Mark

  • 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

  • (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

  • Statement cache  in connection cache

    In my application , i have implemented connection cache mechanism using OracleConnectionImpl class, my application
    gets the connection from connection cache and it makes JDBC calls(SELECT,UPDATE),and returns connection back to connection cache.
    i am doing above steps repedetily, i am trying to implement statement cache mechanism for performance reasons, is statement cache
    mechanism is suitable for above scenario.
    i learned that statement chache is associated with a physical connection, in my case i am getting physical connection instances from a connection cache ,
    using the connection for making JDBC calls and return back to cache. i am using several physical connection instances using connection cache,
    is statement cache suitable for my application?
    i need some help
    thanks

    Hi Elango,
    Thank you, I have downloaded latest jdbc driver (9.2) as u suggested, now it's working well, but i found another problem in my application, as am using CLOB datatypes in my application, when i changed my driver classes to above one i am getting following problem while working with CLOB.
    here i am giving my error stack:
    java.io.IOException: No more data to read from socket
    at oracle.jdbc.dbaccess.DBError.SQLToIOException(DBError.java:716)
    at oracle.jdbc.driver.OracleClobWriter.flushBuffer(OracleClobWriter.java:270)
    at oracle.jdbc.driver.OracleClobWriter.close(OracleClobWriter.java:232)
    my application code as follows
    BufferedReader xmlReader = new BufferedReader(new StringReader(clobXML)); //my xml string
    CLOB clob = ((OracleResultSet) dbresultset).getCLOB(1);
    Writer writer = clob.getCharacterOutputStream();
    // writing xml into clob
    String xmlString = "";
    while ((xmlString = xmlReader.readLine()) != null) {
    writer.write(xmlString);
    xmlReader.close();
    writer.close(); //problem here
    when i am trying to close or flush the stream,it's giving above problem, otherwise it's working fine, but no data is stored in database.
    the above code was working fine with my old driver classes.
    any idea?
    Thanks,
    Sasi

Maybe you are looking for