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

Similar Messages

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

Error making initial connections for pool

          I'm using WLS6.1 on NT, trying my personal implementation of a connector (non
          CCI pattern) with a particular EIS.
          i'm having this error... what depends from?:
          ####<25-ott-00 19.52.41 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190014> <Initializing connection pool for resource adapter
          BlackBoxNoTx.>
          ####<25-ott-00 19.52.42 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190010> <Unable to determine Resource Principal for Container
          Managed Security Context.>
          ####<25-ott-00 19.52.42 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190035> <There was/were 1 physical connection(s) created with
          the following Meta Data: Product name of EIS instance: DBMS:cloudscape Product
          version of EIS instance: 3.5.1 Maximum number of connections supported from different
          processes: 0 User name for connection: null>
          ####<25-ott-00 19.52.42 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190026> << BlackBoxNoTx > Connection Pool initialization has
          completed successfully.>
          ####<25-ott-00 19.52.42 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190014> <Initializing connection pool for resource adapter
          SMJConnector.>
          ####<25-ott-00 19.52.42 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190010> <Unable to determine Resource Principal for Container
          Managed Security Context.>
          ####<25-ott-00 19.52.47 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190010> <Unable to determine Resource Principal for Container
          Managed Security Context.>
          ####<25-ott-00 19.53.06 CEST> <Error> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190024> << SMJConnector > Error making initial connections
          for pool. Reason: examplescnnct.ConnectionImpl>
          ####<25-ott-00 19.53.06 CEST> <Warning> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190025> << SMJConnector > Connection Pool has been initialized
          with no connections.>
          ####<25-ott-00 19.53.06 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <main> <system> <> <190026> << SMJConnector > Connection Pool initialization has
          completed successfully.>
          ####<25-ott-00 19.54.30 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <Application Manager Thread> <> <> <190027> << SMJConnector > Shutting down connections.>
          ####<25-ott-00 19.54.30 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          <Application Manager Thread> <> <> <190028> << SMJConnector > Connections shutdown
          successfully.>


Have you configured your principal map? Connection pools are initially populated using the
          default ("*") principal from the map.
          http://edocs.bea.com/wls/docs61/jconnector/config.html#1237429
          HTH.
          FilAiello wrote:
          > I'm using WLS6.1 on NT, trying my personal implementation of a connector (non
          > CCI pattern) with a particular EIS.
          >
          > <examplesServer>
          > <main> <system> <> <190010> <Unable to determine Resource Principal for Container
          > Managed Security Context.>
          > ####<25-ott-00 19.52.42 CEST> <Info> <Connector> <semarmw0780> <examplesServer>
          Tom Mitchell
          [email protected]
          Very Current Beverly, MA Weather
          http://www.tom.org:8080

How can I make WL 8.1 flush the cache and/or pool for 1.1 EJBs

Hi,
I'm using 1.1 deployment descriptors for my CMP entity bean that were previously
used in the WL 5.1 version of my project.
Things do get deployed but I've observed confusing information when monitoring
the EJB via Admin Console.
What appears is that the Weblogic container is not flushing the cache and/or pool
after the bean has finished processing and also a sufficient time has expired
(i.e. the idle-timeout-seconds)
From what I've understood via the on-line information is that each EJB has its
own cache (since I've not done anything special for that) and the instance in
cache is only passivated when the cache is full and the server need to activate
another instance. On passivation, it appears to be returning the instance to the
pool. But its unclear/undocumented when the pool is cleared, if at all.
What I want is that:
1. A way to get my cached instance passivated
2. A way to get my pooled instance flushed.
The reason I'm looking into this is becasue in my case it appears that the cached/pooled
instance are contributing to OutOfMemory errors and because of the nature of requirements,
etc. we need to have the cache size be high for certain processing.
Thanks
Parasher

I think it's probably best to contact technical support about this.
There are different patches for different versions of WLS.
I'd mention 'CR128026' to them to get started.
-thorick
"Parasher" <[email protected]> wrote:
>
Hi,
Thank you for your reply !
How can I get more information about this patch and the patch itself
Is there a way I can look it up online or do I have to contact the support
folks
and if so what should I need to tell them to convey which patch I'm talking
about.
Thank you in advance.
Parasher
"thorick" <[email protected]> wrote:
Hi,
If you use 'Database' concurrency, then there is a patch available for
some 8.1
service
packs to enable idle-timeout-seconds on the cache. I believe that this
will be
standard
feature with the next service pack. There is no comparable mechanism
for the
pool in 8.1,
this is a feature that is coming with the next major release of WLS.
If the
8.1 patch works
for you, it can save you memory during off peak usage times. Notethat
this
patch does not
work for 'Exclusive' concurrency.
-thorick

Why is the download speed for Creative Cloud updates and initial software installation so slow?

Why is the download process for Adobe Creative Cloud updates and initial installations so slow? I can download and update other software from other providers almost an order of magnitude faster. This slow download problem has been present since I started using Creative Cloud soon after it was initially offered.
Adobe customer support maintains that there is no throttling at Adobe's end, and that no one has complained about this problem -- this forum shows the latter not to be true.
What is the problem?

Hi ErstwhileCreative,
I don't think I've ever checked the download speed but the installers are definitely large files, many several GB. It might seem longer because the download immediately progresses into the installation at 50%
- Dave

Why Inner join or Outer join is not used for Pool or Cluster tables ?

Hi SAP-ABAP Experts .
With Due Regards .
May u explain me why Inner join or Outer join is not useful for Pool or Cluster tables ?
because peoples advised not use Joins for Pool and Cluster tables , What harm will take place , If we do this ?
Best Regards to all : Rajneesh

Both Pooled and Cluster Tables are stored as tables within the database. Only the structures of the two table types which represent a single logical view of the data are defined within the ABAP/4 Data Dictionary. The data is actually stored in bulk storage in a different structure. These tables are commonly loaded into memory (i.e., 'buffered') due to the fact they are typically used for storing internal control information and other types of data with little or no external (business) relevance.
Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. On a pooled or cluster table:
Secondary indexes cannot be created.
You cannot use the ABAP/4 constructs select distinct or group by.
You cannot use native SQL.
You cannot specify field names after the order by clause. order by primary key is the only permitted variation.
I hope it helps.
Best Regards,
Vibha
Please mark all the helpful answers

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)

Caching initial contexts

I have read the posts about caching initial context lookups and have
implemented the solution and seen some benefits.
I am dealing with a third party application that I cannot change.
When I put my InitialContextFactory in the architecture I also logged
how many getInitialContext() calls were being made - I was absolutely
shocked - often 4+ per user transaction. I suspect that the code gets
one, does a call and dereferences all over the place.
90% of InitialContexts had the same environment passed to the getIC()
call so it struck me that what I should do is create a pool of IC, and
in my factory just serve one from the pool.
So, the question is, what is the best way of detecting when the IC has
been dereferenced so I know I can serve it again from my pool?
I presume this is a generic pool problem when you can't guarantee that
your client's will be good citizens and call a close() method or
similar.
I've posted here as it is performance related; also, is there any
reason why what I am doing is not a good idea?
Can the client do something with the IC which means it is not suitable
for use by another client? If so, can I detect this so I may discard?
As always, many thanks in advance.
Presuming I can get it to work I will post the code so that we can all
share ;-)
Cheers
Ed

Why don't you instrument your factory then to give out your own
implementation of InitialContext that will in fact only wrap a "loaner"
InitialContext every time a method is invoked on it and before returning
the value to the caller will put the real InitialContext back to the
pool to be reused by another one.
Then your clients can do whatever they want with those ICs and still
would not cause so big performance hits.
It's just an idea that just came to mind and I haven't tested it so it
might have flaws but it looks viable.
--dejan
Ed Barrett wrote:
The application is a third-party product that cannot be changed.
By introducing the factory you gave below (thanks!) we put the application
back under the load test and saw minimal improvements (like 1% response
time).
I then instrumented the factory with a system.out on finalize and noticed
that a factory instance is created for each call to getInitialContext() - is
this the way that WLS/J2EE works? I would have hoped that factories were
shared or something. What we did see is that for one user request a number
(sometimes 5!) ICs were being created ;-( Obviously the lookup cache is a
class instance and shared across the lot.
So then I started to think about pre-creating ICs and haveing a pool for the
default ones (environment specifies URL and no security details or the
like). Trouble is how to implement such when you cannot change the client
code to call a factory return method (such as returnToPool()).
Any ideas would be appreciated
"Dimitri I. Rakitine" <[email protected]> wrote in message
news:[email protected]...
I've ran into this problem while porting 5.1 application (JNDI lookups
were
super-cheap) to 6.1 (where they are not so cheap due to
serialization/deserialization)
and did this test to see if this indeed was the problem. As you saw I
didn't bother to
cache InitialContext's - I just cached JNDI lookups and that resulted in
very significant
performance improvements.
Which application are you testing it with?
Graham <[email protected]> wrote:
Dimitri,
We did this but did not see that much improvement over the default way -
we
are using 6.1 sp2.
We put some messages in our factory and found that the client code often
created over 4 ICs for one user click - aaggghhhh!! As I say we cannot
change their code but if we could take the time to create an IC away
from
the online response we feel we would save some time.
We also observed a new instance of the IC factory being created every
time a
new IC was created - is this what you would expect?
I think this is what NamingManager.getInitialContext() is supposed to do.
Cheers
Ed
"Dimitri I. Rakitine" <[email protected]> wrote in message
news:[email protected]...
Caching InitialContext's will probably not quite solve the problem,
because lookup()'s are expensive (in 6.x), so, caching lookup results
will result in performance improvements.
If you cannot change the 3'rd party code and all it does is:
... DataSource ds = (DataSource)new InitialContext().lookup(".....");
or similar, you can add caching by implementing your own InitialContext
factory,
for example: (extremely simplistic)
Startup class :
System.setProperty("java.naming.factory.initial",
"myjndi.InitialContextFactory");
where
myjndi.InitialContextFactory is :
public class InitialContextFactory implements
javax.naming.spi.InitialContextFactory {
public Context getInitialContext(Hashtable env) throws
NamingException
Context ctx = new
weblogic.jndi.WLInitialContextFactory().getInitialContext(env);
return
(Context)Proxy.newProxyInstance(ctx.getClass().getClassLoader(),
new Class[]
{ Context.class },
new
ContextHandler(ctx));
and myjndi.ContextHandler is:
public class ContextHandler implements InvocationHandler {
Context ctx;
static Hashtable cache = new Hashtable();
public ContextHandler(Context ctx) {
this.ctx = ctx;
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
try {
Object retVal;
if("lookup".equals(method.getName()) && args[0] instanceof
String) {
retVal = cache.get(args[0]);
if(retVal == null) {
retVal = method.invoke(ctx, args);
cache.put(args[0], retVal);
} else {
retVal = method.invoke(ctx, args);
return retVal;
} catch(InvocationTargetException oops) {
throw oops.getTargetException();
Ed <[email protected]> wrote:
Adarsh,
We agree it is a brilliant idea - now just to work out how to do it.
As you cannot always guarantee to be able to change the client code
you cannot use normal pooling techniques:
getObjectFromPool()
// do work
returnObjectToPool()
So, the client code needs an InitialContext. We can put in our own
Factory and intercept the getInitialContext() calls. This method
must
return class javax.naming.Context - therefore the only way I can see
to spot when the class is dereferenced is to extend the class and add
a finalize() method that notifies the factory.
The trouble I believe is that the class cannot be "rescued" in the
finalize() method (i.e. "I'm dying - take me back" ;-). If it simply
told the factory to add another one to its pool this would mean that
the new IC create "hit" would be in garbage collection (i.e. the
users
will pay somewhere along the line) - is this correct?
Anyone any ideas on a solution? I have discovered out code create
HUNDREDS of contexts in an hour and discards them very quickly. Be
nice to be able to cache them!
Cheers
Ed
"Adarsh Dattani" <[email protected]> wrote in message
news:<[email protected]>...
Ed,
This a brilliant idea. We are planning something similar too. We
first
want to create a pool of LDAP connections as apps make extensive
calls
to
LDAP. Did you check-out the object pooling api at Jakarta Commons.
It
deserves a close look.
http://jakarta.apache.org/commons/pool/index.html
Thanks,
Adarsh
"Ed" <[email protected]> wrote in message
news:[email protected]...
I have read the posts about caching initial context lookups and
have
implemented the solution and seen some benefits.
I am dealing with a third party application that I cannot change.
When I put my InitialContextFactory in the architecture I also
logged
how many getInitialContext() calls were being made - I was
absolutely
shocked - often 4+ per user transaction. I suspect that the code
gets
one, does a call and dereferences all over the place.
90% of InitialContexts had the same environment passed to the
getIC()
call so it struck me that what I should do is create a pool of IC,
and
in my factory just serve one from the pool.
So, the question is, what is the best way of detecting when the IC
has
been dereferenced so I know I can serve it again from my pool?
I presume this is a generic pool problem when you can't guarantee
that
your client's will be good citizens and call a close() method or
similar.
I've posted here as it is performance related; also, is there any
reason why what I am doing is not a good idea?
Can the client do something with the IC which means it is not
suitable
for use by another client? If so, can I detect this so I may
discard?
As always, many thanks in advance.
Presuming I can get it to work I will post the code so that we can
all
share ;-)
Cheers
Ed
Dimitri
Dimitri

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 retrieve a prepared statement from prepared statement cache?

Hi All,
I have created the connection pool during application server startup. The connection pool are getting created successfully. I have also created the prepared statements and stored as part of each connection in the connection pool.
can anyone please tell me on how do I retrieve a prepared statement from prepared statement cache from a connection object.
Any pointers to info source will be REALLY appreciated.
Many Thanks in Advance,
C R Baradwaj

Raghuram Bharatwaj C wrote:
Hi Joe,
I have created a connection poool in my startup class and created the
neccessary prepared statements for a each connection. I have 10 prepared
statements to be created for each connection. I have created all the 10 prepared statements using the loop as mentioned below
String [] epc_stmts;
private java.sql.PreparedStatement[] _pstmts;
if (epc_stmts!= null)
               _pstmts = new PreparedStatement [len = epc_stmts.length];
               for (i=0; i<len; i++)
                    _pstmts[i] = db.prepareStatement (epcstmts);
I have closed the connection after the prepared statements are created.
Now, How do i access a prepared statement from the connection object.
Nothing. Are you talking about a WebLogic pool? If so, then therafter,
whenever your application gets a pool connection, when it calls
prepareStatement() with the same SQL as you prepared those statements,
it will get a cached statement. Your array is unnecessary.
Joe
>
Many Thanks in Advance,
C R Baradwaj

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.

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

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

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"

Similar Messages

Maybe you are looking for