JDBC connection in EJB

In EJBs, we can always spawn a JDBC connection using the internal server side driver through defaultConnection() or kprb. My question is, can we spawn any other kind of connection from an EJB to another database on some remote machine, this would involve using the thin or oci drivers, i try but get security exceptions and access privilege exception though the account i use is privilegded for database operations. Can someone answer my question please.

see reply in one of the four other forums you posted the same question to !!

Similar Messages

JDBC connection in EJB (Sorry i know this is a JSP forum but someone might have the a

In EJBs, we can always spawn a JDBC connection using the internal server side driver through defaultConnection() or kprb. My question is, can we spawn any other kind of connection from an EJB to another database on some remote machine, this would involve using the thin or oci drivers, i try but get security exceptions and access privilege exception though the account i use is privilegded for database operations. Can someone answer my question please.

see reply in one of the four other forums you posted the same question to !!

Jdbc connection in EJB using wsad 5.0

Hi,
I want to develop a small application using Ejbs by using oracle 9i as D/b, wsad 5.0 as app server . The problem is i am not able to connect to oracle database in WSAD. What i am doing is i have installed Oracle 9i in my system and has given the Global database name as "samp" while installation . I open my SQL plus with username scott and password tiger and i am able to do all my sql queries successfully.
Now coming to WSAD,
while creating a JDBC connection using Oracle 9i driver,
i ve opened in Data perspective and in that go to DB Servers -> Right click -> New Connection
There a window is opened for Database Connection.
We need to fill the fields there.
I have given samp as Global d/b name while installing Oracle 9i .
In the window , the feilds are
Connection Name : conn
Database Name : samp
user id : scott
password : tiger
D/b vendor type: Oracle 9i
Jdbc Driver : Oracle Thin Driver
Host : 127.0.0.1
port No: 1521
class location : c:\oracle\ora90\jdbc\lib\classes12.zip
connection url : jdbc:oracle:thin:@127.0.0.1:1521:samp
the class location and connection url are automatically coming.
and please check whether all fields are correct or not
Is this the correct way.
Next in code if i want to connect to database should i use connection establish commands again or i can directly use create statement or prepare statement.
Please reply.
Thanks

Create New Server and configure it properly
It will work
procedure is as follows:
Pls visit the following link:
http://www.webagesolutions.com/knowledgebase/waskb/waskb001/index.html
Adding a Oracle9i DataSource from WSAD5
Bibhas Bhattacharya, Web Age Solutions Inc.
Before you begin, make sure that you have Oracle installed and a database is created. In this document we will use a database called MALL.
Create a WAS V5 Server
If you don't already have a WebSphere V5 server created, do so following these steps. Switch to the Server perspective. Right click in the Server Configuration view and select New->Server and Server Configuration.
Name the server WASV5. Make sure that the Server type is set to WebSphere version 5.0->Test Environment. Click on Finish.
Add the Database User
In WSAD5, the default user ID and password to be used by a DataSource are first entered as a JAAS authentication entry.
In the Server Configuration view, double click on WASV5 to open the configuration editor. Click on the Security tab. Next to the JAAS Authentication Entries list click on Add and add the user.
Add the JDBC Driver
Still in the server configuration GUI click on the DataSource tab. You can add the DataSource at the server level or at the node level. We will add it at the server level. Make sure that the Server Settings is expanded. Next to the JDBC providers list click on Add.
Select the following options:
Database type: Oracle
JDBC provider type: Oracle JDBC Thin Driver or the XA version of it if you need two phase commit transaction.
Click on Next.
Set the name to Oracle Thin Driver.
Notice that the location of the driver's class is automatically set to ${ORACLE_JDBC_DRIVER_PATH}/classes12.zip. Here, ORACLE_JDBC_DRIVER_PATH is a node level variable. We need to make sure that the variable is pointing to the correct directory where Oracle's JDBC driver is installed. In our case, we had installed Oracle in c:\oracle. This had installed the JDBC driver class in C:/oracle/ora81/jdbc/lib/classes12.zip.
In the server configuration GUI click on the Variables tab. Under the Node settings select ORACLE_JDBC_DRIVER_PATH from the Defined variables list. Click on Edit and set the value to C:/oracle/ora81/jdbc/lib.
Add the DataSource
Click on the DataSource tab again. Select the Oracle Thin Driver you had created in the previous step. Click on Add next to the Data source defined in the JDBC provider selected above list.
Select the following options:
Select the type of JDBC Driver: Oracle JDBC Thin Driver.
Select the data source type: Unless you will be testing your application with WAS V4, select Version 5.0. You can not use a V4 DataSource from a J2EE 1.3 EJB module running in WebSphere V5.
Click on Next.
Enter these key attributes in this screen:
Name: My Oracle DataSource
JNDI Name: jdbc/MyDataSource
DataSource helper class name: com.ibm.websphere.rsadapter.OracleDataStoreHelper. Should be selected by default. The helper class is needed if you wish to access IBM extensions to JDBC. For more details search in WSAD help for "WSDataSource interface".
Component-managed authentication alias: Set this if you wish to lookup the DataSource using its global JNDI name or using the java:comp/env/ name space and have set the authentication type of the resource reference to Application. Select the JAAS entry you had created. That is, Database user.
Container-managed authentication alias: Set this if you intend to lookup the DataSource using the java:comp/env/ name space and have set the authentication type of the resource reference to Container. Select the JAAS entry you had created. That is, Database user.
Use this data source in container managed persistence (CMP): Check on if you intend to use the DataSource from CMP EJBs.
Click on Next.
You need to set these properties:
databaseName: MALL in our case.
URL: jdbc:oracle:thin:@noble.webagesolutions.com:1521:MALL. In my case the server host name is noble.webagesolutions.com. The listener port number is 1521 (usually the default in most Oracle installations).
Click on Finish.
You have finished adding the DataSource. Save the server settings by clicking Control+S. Close the server configuration GUI.
Testing the DataSource
There is no out of the box way to test the DataSource. You can create a simple Servlet and add the following code:
public void doGet(HttpServletRequest req, HttpServletResponse resp)
javax.sql.DataSource ds = null;
java.sql.Connection con = null;
java.io.PrintWriter out = resp.getWriter();
resp.setContentType("text/html");
try {
out.println("Looking up DataSource ");
javax.naming.InitialContext ctx = new javax.naming.InitialContext();
ds = (javax.sql.DataSource) ctx.lookup("jdbc/MyDataSource");
out.println("Getting connection ");
con = ds.getConnection();
con.close();
} catch (Exception e) {
e.printStackTrace(out);
out.println("Done ");
Feedback
Your e-mail:
Rate this article:
Very useful Somewhat useful Not bad Needs many corrections
Comments:

Ias support for EJB, JSP/servlets,JDBC, connection pooling, XML, SOAP, load balancing etc

Please let me know where I can find more information regarding iPlanet usage/deployment/configuring/tuning etc for support of technologies - like EJB, JSP/servlets, JDBC, connection pooling, XML, load balancing, JDBC & Transactions
(I have already read the 'Getting Started with the iPlanet Application Server' part five and six - http://developer.iplanet.com/appserver/testdrive/partfive.jsp and partsix.jsp)(I am using the ias testdrive version).

Hi,
It's difficult to explain unless the J2EE architecture is understood. Also, explaining things like load balancing, Transactions, tuning, are bit vague and could blow the disk space of this site.
To get started, the best way is to test the sample applications and the best part is you don't require internet connection to follow each steps. Install iWS and iAS, open browser, type in http://hostname:port/ias-samples/index.html. You can find links to the sample applications bundled. Please follow the steps given on deploying the application. This will enable you to a higher level.
Regards
Ganesh .R
Developer Technical Support
Sun Microsystems
http://www.sun.com/developers/support

JDBC connection pool failures when used by JMS stores

 We are using WebLogic 6.1 sp2. We defined a separate connection pool for use by
 a JMS Store.
 <JDBCConnectionPool Name="sybaseJMSPool"
 Targets="cluster00"
 InitialCapacity="2"
 MaxCapacity="10"
 DriverName="com.sybase.jdbc2.jdbc.SybDriver"
 Properties="[email protected]@;[email protected]@;charset=utf8"
 URL="jdbc:sybase:Tds:@jms.db.host@/@jms.db.name@"/>
 (note that the @xxx@ string are replaced by actual values).
 We are using Sybase Jconnect 5.5 to a Sybase ASE 12.5 database.
 We deployed this configuration on a number of environments (testing, staging,
 ..). The actual hardware and network configuration is different for the different
 system, but the WebLogic domain stays the same regarding this issue.
 On the test system we frequently get the following exceptions:
 <Aug 13, 2002 1:56:04 PM CEST> <Alert> <JMS> <www00-test> <node00>
 <ExecuteThread: '6' for queue: 'JMS.TimerClientPool'> <> <> <040048>
 <JMSServer "JMSServer00", store failure while writing message for topic
 OrderChangeTopic, java.io.IOException: JMS JDBC store, connection pool =
 <sybaseJMSPool>, prefix = <JMS00>: write failed
 java.sql.SQLException: JZ006: Caught IOException:
 com.sybase.jdbc2.jdbc.SybConnectionDeadException: JZ0C0: Connection is already
 closed.
 at com.sybase.jdbc2.jdbc.ErrorMessage.raiseErrorCheckDead
 (ErrorMessage.java:715)
 at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3124)
 at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1412)
 at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1341)
 at com.sybase.jdbc2.jdbc.SybStatement.doCancel(SybStatement.java:564)
 at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1672)
 at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate
 (SybStatement.java:1625)
 at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate
 (SybPreparedStatement.java:91)
 at com.p6spy.engine.logging.P6LogPreparedStatement.executeUpdate
 (P6LogPreparedStatement.java:179)
 at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:293)
 at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:1246)
 at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
 at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
 .>
 java.io.IOException: JMS JDBC store, connection pool = <sybaseJMSPool>, prefix
 = <JMS00>: write failed
 java.sql.SQLException: JZ006: Caught IOException:
 com.sybase.jdbc2.jdbc.SybConnectionDeadException: JZ0C0: Connection is already
 closed.
 at com.sybase.jdbc2.jdbc.ErrorMessage.raiseErrorCheckDead
 (ErrorMessage.java:715)
 at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3124)
 at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1412)
 at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1341)
 at com.sybase.jdbc2.jdbc.SybStatement.doCancel(SybStatement.java:564)
 at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1672)
 at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate
 (SybStatement.java:1625)
 at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate
 (SybPreparedStatement.java:91)
 at com.p6spy.engine.logging.P6LogPreparedStatement.executeUpdate
 (P6LogPreparedStatement.java:179)
 at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:293)
 at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:1246)
 at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
 at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
 at weblogic.jms.store.JDBCIOStream.throwIOException
 (JDBCIOStream.java:1213)
 at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:1256)
 at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
 at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
 Before that this message appeared:
 <Aug 13, 2002 11:31:16 AM CEST> <Error> <ConnectionManager> <www00-test>
 <node00> <ExecuteThread: '26' for queue: 'default'> <> <> <000000>
 <Closing: 'weblogic.rjvm.t3.T3JVMConnection@795af6' because of: 'Server
 received a message over an uninitialized connection: 'JVMMessage from: 'null'
 to: '-4555218188801970213S:192.168.13.1:[7001,7001,7002,7002,7001,7002,-
 1]:ADIS:node00' cmd: 'CMD_REQUEST', QOS: '101', responseId: '1',
 invokableId: '287', flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev
 offset: '34'''>
 This problem did not occur on another system which was used during a 2 day stress
 testing session.
 It seems that the problem occurs after a period in which no user request where
 made. The user requests trigger EJB's that start sending JMS messages.
 When the problem occurs, the JMS messaging systems seems to lock up as no messages
 are received anymore by the different listeners (MDBs).
 Undeploying and redeploying the JBDC connection pool solves the problem. This
 solution is unacceptable in case of a production system.
 A similarly defined connection pool, which is used by the EJBs to make database
 connection, does not manifest this problem.
 <JDBCConnectionPool Name="sybasePool"
 Targets="cluster00"
 InitialCapacity="10"
 CapacityIncrement="5"
 MaxCapacity="50"
 PreparedStatementCacheSize="150"
 DriverName="com.sybase.jdbc2.jdbc.SybDriver"
 Properties="[email protected]@;[email protected]@;JCONNECT_VERSION=6;charset=utf8"
 URL="jdbc:sybase:Tds:@db.host@/@db.name@"/>
 The JDBC connection pool is used as follows by the JDBC store
 <JMSJDBCStore ConnectionPool="sybaseJMSPool" Name="JDBCStore00" PrefixName="JMS00"/>
 <JMSServer Name="JMSServer00" Store="JDBCStore00" Targets="node00">
 <JMSTopic JNDIName="ADIS.JMSError" JNDINameReplicated="false" Name="ErrorTopic"/>
 <JMSTopic JNDIName="ADIS.Status"
 Name="StatusTopic" RedeliveryDelayOverride="300000"/>
 <JMSTopic JNDIName="ADIS.OrderChange" JNDINameReplicated="false"
 Name="OrderChangeTopic" RedeliveryLimit="3"/>
 </JMSServer>
 Turning on the "Test Reserved Connection" with a appropriate test table does not
 help.
 Some sources on the internet tell us that JZ0C0 errors in the Jconnect driver
 can be related to network problems. Nevertheless the connection pool should be
 able to cope with this.
 Can you provide any solution for this ? Or give us hints what can cause the problem


Zhenhao Qi wrote:
thanks! Joe.
The SQL statement itself can no longer be simplified, the long excuation time is due to the database size and complicated Select criteria. I can easily reproduce the problem by using this SQL. I tried "BEA's Oracle driver (Type 4): Version 8.1.7,9.0.1,9.2.0". the question can be dissect into 2 pieces:
1) why the jdbc connection (using oracle.jdbc.OracleDriver) won't return anything if the SQL execution time > 5min, that is probably the Oracle's problem
2) why the occupied connection pool won't release even I set "Statementtimeout=600", this is Weblogic's problem.
ZhenhaoHi. Yes, (1) is oracle's problem. (2) may also be. The JDBC spec has very few
allowances for one thread to interrupt a second thread's JDBC call. If we
transmit your timeout request by calling setQueryTimeout() on the oracle
statement, and if you have a weblogic-controlled transaction we call
Statement.cancel() on any ongoing statement, we end up relying on whether
the Oracle driver implements and responds to those calls.
Are you doing weblogic-controlled transactions? Are you/can you
call Statement.setQueryTimeout() on your statements, or are these
generated JDBC queries?
If you can duplicate the problem using the weblogic.jdbc.oracle.OracleDriver
we have some other debug avenues. This would be good even if you really
want to use the thin driver, because we will do the same JDBC calls to
either driver, and the debug would prove (if) we set up a query timeout
and if we call cancel(). If we do, then we can know that it is the Oracle
driver failing in these regards.
Joe

JDBC, JMS and EJB transactions - possible problem?

Hello,
          I am using Oracle 9, Weblogic 8.1 SP 4, MyEclipse and
          XDoclet.
          In my current project I have the following piece of code
          in one of my message driven beans (code cited as pseudocode
          without unnecessary details):
          * @ejb.bean name="MyMessageProcessor"
          * display-name="Display name for a MyMessageProcessor"
          * jndi-name="ejb/MyMessageProcessor"
          * description="Bean MyMessageProcessor"
          * destination-type="javax.jms.Queue"
          * transaction-type="Container"
          * acknowledge-mode="Auto-acknowledge"
          * subscription-durability="Durable"
          * generate="false"
          * @ejb.transaction type="Required"
          public class MyMessageProcessor implements MessageDrivenBean, MessageListener {
          public void onMessage(Message msg) {
               try {
                    //obtaining connections to two different databases via JNDi
                    java.sql.Connection connOne =
                    ((DataSource)ctx.lookup("DataSourceOne")).getConnection();
                    java.sql.Connection connTwo =
                         ((DataSource)ctx.lookup("DataSourceTwo")).getConnection();
                    // performing some UPDATEs and INSERTs on connOne and connTwo
                    // calling some other methods of this bean
                    //creating the reply JMS message and sending it to another JMS queue
                    Message msgTwo = this.createReplyMessage(msg)
                    this.queueSender.send(msgTwo);
                    //commiting everything
                    this.queueSession.commit();
               } catch (Exception ex) {
               try {
                    if (this.queueSession!=null) this.queueSession.rollback();
               } catch (JMSException JMSEx) {};
               this.context.setRollbackOnly();
          Some days ago (before the final remarks from my client) there used to be only one DataSource configurated on the basis of the
          connection pool with non-XA jdbc driver. Everything worked fine
          including the transactions (if anything wrong happend not only wasn't the replymessage sent, but also no changes were written
          to database and the incomming message was thrown back to the my bean's
          queue).
          When I deployed the second DataSource I was informed by an error message, that only one non-transactional resource may
          participate in a global transaction. When I changed both datasources
          to depend on underlying datasources with transatcional (XA) jdbc drivers, everything stopped working. Even if
          EJB transaction was theoretically successfully rolledbacked, the changed were written to the database
          and the JMS message wasn't resent to the JMS queue.
          So here are my questions:
               1. How to configure connection pools to work in such situations? What JDBC drivers should I choose?
               Are there any global server configurations, which may influence this situation?
               2. Which jdbc drivers should I choose so that the container was able to rollback the database transactions
               (of course, if necessary)?
               3. Are there any JMS Queue settings, which would disable the container to send message back to the
               queue in case of setRollbackOnly()? How should be the Queue configurated?
          As I am new to the topic and the deadline for the project seems to be too close I would be grateful
          for any help.
          This message was sent to EJB list and JDBC list.
          Sincerely yours,
          Marcin Zakidalski

Hi,
          I found these information extremely useful and helpful.
          The seperate transaction for sending messages was, of course, unintentional. Thanks a lot.
          Anyway, I still have some problems. I have made some changes to the
          code cited in my previous mail. These changes included changing QueueSessions
          to non-transactional. I also set the "Honorate global transactions" to true.
          I am using XA JDBC driver. After setting "Enable local transactions" to false
          (I did it, because I assume that JDBC transactions should be part on the global
          EJB transaction) I got the following error:
          java.sql.SQLException: SQL operations are not allowed with no global transaction by default for XA drivers. If the XA
          driver supports performing SQL operations with no global transaction, explicitly allow it by setting
          "SupportsLocalTransaction" JDBC connection pool property to true. In this case, also remember to complete the local
          transaction before using the connection again for global transaction, else a XAER_OUTSIDE XAException may result. To
          complete a local transaction, you can either set auto commit to true or call Connection.commit() or Connection.rollback().
          I have also inspected the calls of methods of bean inside of onMessage() method just to check, whether
          the transactions are correctly initialized (using the weblogic.transaction.Transaction class).
          My questions are as follows:
          1. Any suggestions how to solve it? I have gone through the google answers on that problem and only
          thing I managed to realize that JDBC must start its own transaction. Is there any way to prohibit it
          from doing that? Can using setAutocommit(true/false) change the situation for better?
          2. How to encourage the JDBC driver to be a part of EJB transaction?
          3. As I have noticed each of ejb method has its own transactions (transactions have different
          Xid). Each method of the bean has "required" transaction attribute. Shouldn't it work in such
          way that if already started transaction exists it is used by the called method?
          4. The DataSources are obtained in my application via JNDI and in the destination environment I will have slight
          impact on the configuration of WebLogic. What is least problematic and most common WebLogic configuration which would
          enable JDBC driver to participate in the EJB transaction? Is it the WebLogic configuration problem or can it be
          solved programmically?
          Currently my module works quite fine when "enable local transactions" for DataSources is set to true, but this way
          I am loosing the ability to perform all actions in one transaction.
          Any suggestions / hints are more than welcomed. This message was posted to jdbc list and ejb list.
          Marcin

Servlets/JDBC vs. servlets/EJB performance comparison/benchmark

I have a PHB who believes that EJB has no ___performance___ benefit
against straightforward servlets/JSP/JDBC. Personally, I believe that
using EJB is more scalable instead of using servlets/JDBC with
connection pooling.
However, I am at a lost on how to prove it. There is all the theory, but
I would appreciate it if anyone has benchmarks or comparison of
servlets/JSP/JDBC and servlets/JSP/EJB performance, assuming that they
were tasked to do the same thing ( e.g. performance the same SQL
statement, on the same set of tables, etc. ).
Or some guide on how to setup such a benchmark and prove it internally.
In other words, the PHB needs numbers, showing performance and
scalability. In particular, I would like this to be in WLS 6.0.
Any help appreciated.

First off, whether you use servlets + JDBC or servlets + EJB, you'll
most likely spend much of your time in the database.
I would strongly suggest that you avoid the servlets + JDBC
architecture. If you want to do straight JDBC code, then it's
preferable to use a stateless session EJB between the presentation layer
and the persistence layer.
So, you should definitely consider an architecture where you have:
servlets/jsp --> stateless session ejb --> JDBC code
Your servlet / jsp layer handles presentation.
The stateless session EJB layer abstracts the persistence layer and
handles transaction demarcation.
Modularity is important here. There's no reason that your presentation
layer should be concerned with your persistence logic. Your application
might be re-used or later enhanced with an Entity EJB, or JCA Connector,
or a JMS queue providing the persistence layer.
Also, you will usually have web or graphic designers who are modifying
the web pages. Generally, they should not be exposed to transactions
and jdbc code.
We optimize the RMI calls so they are just local method calls. The
stateless session ejb instances are pooled. You won't see much if any
performance overhead.
-- Rob
jms wrote:
>
I have a PHB who believes that EJB has no ___performance___ benefit
against straightforward servlets/JSP/JDBC. Personally, I believe that
using EJB is more scalable instead of using servlets/JDBC with
connection pooling.
However, I am at a lost on how to prove it. There is all the theory, but
I would appreciate it if anyone has benchmarks or comparison of
servlets/JSP/JDBC and servlets/JSP/EJB performance, assuming that they
were tasked to do the same thing ( e.g. performance the same SQL
statement, on the same set of tables, etc. ).
Or some guide on how to setup such a benchmark and prove it internally.
In other words, the PHB needs numbers, showing performance and
scalability. In particular, I would like this to be in WLS 6.0.
Any help appreciated.--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com

Open/total jdbc connections

With Oracle9iR2 AS installed, I notice that there are always open JDBC connections. I explicitly close them from all my JSP files (and the statement and the resultset objects as well). Actually, the total JDBC connections are always 2 times the open JDBC connections.
The DataSource class I use is com.evermind.sql.DriverManagerDataSource. Is this a problem? Will this be corrected in any future release?
Thanx

Interesting thread. Have also had problems with the connection pool (903 standalone).
One problem in particular is that if min-connections is used, then those pool-connections are really never closed "physically". This means that a lot of open cursors are never released in the db (even though the "connections" used by the code from the pool are closed). Not so good under heavy load.
Posting a snippet from a connection pool entry we have. Maybe it will help some of you guys.
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="SomeDS"
location="jdbc/SomeDBCoreDS"
xa-location="jdbc/xa/SomeDBXADS"
ejb-location="SomeDB"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="user"
password="pwd"
url="jdbc:oracle:thin:@127.0.0.1:1521:SOMESID"
inactivity-timeout="300" <-- Will close connections after 300 sec of inactivity
min-connections="0"
max-connections="20" <-- Larger on prod machine of course
stmt-cache-size="100"
/>
I have experimented wildly with these settings and this is the most stable. Sure, it's nice to always have connections ready in the pool. But as I said. Open cursors WILL accumulate in your db if you use the min-connections set to a positive number (check your v$). This is our experience anyway. These settings have stopped us from getting db errors such as maximum open cursors exceeded and too many connections open using 903.
Regards,
Jonas

Total JDBC connections rising steadily

Our J2EE application has been crashing recently. The app stops responding to requests and is eventually restarted by OPMN. I have been monitoring it through the enterprise manager web page since the the crashes seem to be related to waiting for database resources. The number of open JDBC connections stays low, always less than 10. However, the total number of JDBC connections rises steadily through the day getting well past 1000. Is this normal?
Does it represent leakage of connections from the pool?
We are using OC4J 9.0.4.0 with a patch to fix the connection pool bug.
The data-source is defined as follows:
<data-source
 class="com.evermind.sql.DriverManagerDataSource"
 name="OracleDS"
 location="jdbc/OracleCoreDS"
 xa-location="jdbc/xa/OracleXADS"
 ejb-location="jdbc/OracleDS"
 connection-driver="oracle.jdbc.driver.OracleDriver"
 username="asuser"
 password="unguessable"
 url="jdbc:oracle:thin:@dbserver:1526:dbinstance"
 inactivity-timeout="30"
/>

The Total number of connections figure indicates the total number of connections that have been opened since OC4J was started.
The Open number of connections figure indicates the total number of connections currently open.
Since you say that the open connections figure stays below 10, this suggests that you do not have a connection leak, but your inactivity time out is too low, and therefore your connections are being closed before they can be reused - hence the large total number of connections.
Good luck.

Problem w. transaction notSupported / releasing JDBC connections

          We are making a call from our EJB client to a stateless session EJB (1) with transaction attribute 'Required' for all methods. From this EJB (1) we get a JDBC connection from the pool and do some JDBC calls (no updates). We then make a call to a method in another stateles session EJB (2) with transaction attribute 'NotSupported' for all methods. In EJB2 we get a JDBC connection from the pool and do some JDBC calls (no updates). Something goes wrong and we catch a SqlException. We then throw a EJBException. So far everything is OK. But now we get a SqlException from the transaction: 'java.sql.SQLException: Connection is currently associated with xid: 970661671558_182.Rollback attempted in the scope of a different transaction'. It seems like the container tries to perform a rollback on the EJB tat doesn't support transactions. Shouldn't the transaction have been suspended when we entered the method in EJB2? Our problem is that the JDBC connection we got from the pool doesn't get released even though we closed it in a finally-statement in both EJB:s. So after some time we are out of free JDBC connections in our connection pool. Does anyone know why this happens?
          /Per


          We are making a call from our EJB client to a stateless session EJB (1) with transaction attribute 'Required' for all methods. From this EJB (1) we get a JDBC connection from the pool and do some JDBC calls (no updates). We then make a call to a method in another stateles session EJB (2) with transaction attribute 'NotSupported' for all methods. In EJB2 we get a JDBC connection from the pool and do some JDBC calls (no updates). Something goes wrong and we catch a SqlException. We then throw a EJBException. So far everything is OK. But now we get a SqlException from the transaction: 'java.sql.SQLException: Connection is currently associated with xid: 970661671558_182.Rollback attempted in the scope of a different transaction'. It seems like the container tries to perform a rollback on the EJB tat doesn't support transactions. Shouldn't the transaction have been suspended when we entered the method in EJB2? Our problem is that the JDBC connection we got from the pool doesn't get released even though we closed it in a finally-statement in both EJB:s. So after some time we are out of free JDBC connections in our connection pool. Does anyone know why this happens?
          /Per

Two jdbc connections in one transaction

Hi 
 
 In a method of a container managed ejb session bean I have two jdbc connections. I've expected, that they will be in the same transaction, so results of any actions performed with first connection will be visible for the second connection, but it is not. 
 I've checked, that there are two sessions at the database, so it seams that there are simply separate transactions. Is it a problem with a ejb-jar.xml (will paste it later), datasource (driver - Oracle Thin non-XA; 1PC selected) or such behaviour can not be achieved in WLS ? 
 
 regards
 
 <?xml version="1.0" encoding="UTF-8"?>
 
 <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
 
 <ejb-jar >
 
 <description><![CDATA[No Description.]]></description>
 <display-name>ConnectionTest1</display-name>
 
 <enterprise-beans>
 <session >
 <description><![CDATA[]]></description>
 
 <ejb-name>ConnectionTest1</ejb-name>
 
 <home>pl.axit.test.ConnectionTest1Home</home>
 <remote>pl.axit.test.ConnectionTest1</remote>
 <ejb-class>pl.axit.test.ConnectionTest1Bean</ejb-class>
 <session-type>Stateless</session-type>
 <transaction-type>Container</transaction-type>
 
 <resource-ref >
 <res-ref-name>jdbc/wowrite</res-ref-name>
 <res-type>javax.sql.DataSource</res-type>
 <res-auth>Container</res-auth>
 </resource-ref>
 </session>
 </enterprise-beans>
 
 <assembly-descriptor>
 <container-transaction>
 <description/>
 <method>
 <description/>
 <ejb-name>ConnectionTest1</ejb-name>
 <method-name>*</method-name>
 </method>
 <trans-attribute>Required</trans-attribute>
 </container-transaction>
 
 </assembly-descriptor>
 </ejb-jar>

Hi,
 are you using XA transactions? Two separate JDBC Connections treated
 within one transactional context will require two phase commit (via
 Emulation or an XA database driver) Please check the connections
 settings within your datasources.
 Rgds,
 Axel van Lil (LMIS.de)
 Lukas Uruski schrieb:
 > I forgot to add, that in administration console in server_name > Monitoring > JTA parameter "Transactions Total Count" increases by one each time method from previous post is invoked.

Thread stuck in socketConnect() while openning JDBC connection

We are suferring a very strange behaviour in one of our servers.
Sometimes a thread stucks for serveral minutes while obtaining a JDBC connection, this is the stack trace down to our method:
"[STUCK] ExecuteThread: '82' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE native
 java.net.PlainSocketImpl.socketConnect(Native Method)
 java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
 java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
 java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
 java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
 java.net.Socket.connect(Socket.java:529)
 oracle.net.nt.TcpNTAdapter.connect(TcpNTAdapter.java:150)
 oracle.net.nt.ConnOption.connect(ConnOption.java:130)
 oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:353)
 oracle.net.resolver.AddrResolution.resolveAndExecute(AddrResolution.java:422)
 oracle.net.ns.NSProtocol.establishConnection(NSProtocol.java:686)
 oracle.net.ns.NSProtocol.connect(NSProtocol.java:246)
 oracle.jdbc.driver.T4CConnection.connect(T4CConnection.java:1056)
 oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:308)
 oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:538)
 oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:228)
 oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
 oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521)
 oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:280)
 oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:482)
 oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:156)
 oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:101)
 weblogic.jdbc.common.internal.XAConnectionEnvFactory.makeConnection(XAConnectionEnvFactory.java:477)
 weblogic.jdbc.common.internal.XAConnectionEnvFactory.createResource(XAConnectionEnvFactory.java:177)
 weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1249)
 weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1166)
 weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:450)
 weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:342)
 weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:419)
 weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:324)
 weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:94)
 weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:63)
 weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1677)
 weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1445)
 weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:446)
 weblogic.jdbc.jta.DataSource.connect(DataSource.java:403)
 weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:364)
 org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:126)
 org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:94)
 org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
 org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.connectInternal(DatasourceAccessor.java:327)
 org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.connectInternal(DatabaseAccessor.java:291)
 org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:558)
 org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1433)
 org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:302)
 org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:570)
 org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:526)
 org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:529)
 org.eclipse.persistence.internal.sessions.IsolatedClientSession.executeCall(IsolatedClientSession.java:133)
 org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:206)
 org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:192)
 org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectOneRow(DatasourceCallQueryMechanism.java:664)
 org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectOneRowFromTable(ExpressionQueryMechanism.java:2582)
 org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectOneRow(ExpressionQueryMechanism.java:2553)
 org.eclipse.persistence.queries.ReadObjectQuery.executeObjectLevelReadQuery(ReadObjectQuery.java:439)
 org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1076)
 org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:740)
 org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1036)
 org.eclipse.persistence.queries.ReadObjectQuery.execute(ReadObjectQuery.java:407)
 org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1122)
 org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2908)
 org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1291)
 org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1273)
 org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1233)
 org.eclipse.persistence.internal.jpa.EntityManagerImpl.executeQuery(EntityManagerImpl.java:778)
 org.eclipse.persistence.internal.jpa.EntityManagerImpl.findInternal(EntityManagerImpl.java:722)
 org.eclipse.persistence.internal.jpa.EntityManagerImpl.find(EntityManagerImpl.java:616)
 org.eclipse.persistence.internal.jpa.EntityManagerImpl.find(EntityManagerImpl.java:495)
 sun.reflect.GeneratedMethodAccessor182.invoke(Unknown Source)
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 java.lang.reflect.Method.invoke(Method.java:597)
 weblogic.deployment.BasePersistenceContextProxyImpl.invoke(BasePersistenceContextProxyImpl.java:106)
 weblogic.deployment.TransactionalEntityManagerProxyImpl.invoke(TransactionalEntityManagerProxyImpl.java:77)
 weblogic.deployment.BasePersistenceContextProxyImpl.invoke(BasePersistenceContextProxyImpl.java:87)
 weblogic.deployment.TransactionalEntityManagerProxyImpl.invoke(TransactionalEntityManagerProxyImpl.java:18)
 $Proxy71.find(Unknown Source)
 com.ericsson.adm.ejb.PromoProcessorMDB.processRequest(PromoProcessorMDB.java:181)
I checked OS tcp_syn_retries, is 5, an exception should be raised after 180 seconds, isnt?
Even more weird is that sometimes a entityManager.find() give us null object even if the database record of the sougth persisted object exists.
It seems that we have a network problem here but WLS / JVM is not throwing exceptions so we cant show to network administrators this problem.
Our Weblogic is version 10.3.4 running on Redhat 5 with kernel 2.63.18-194.e15.
JDK reports itself as "Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)".
We have the exact replica of the faulty server (hardware and configuration) running the same application in the same domain connected to the same network switch connecting to the same Oracle instance but in that server we haven't suffer such problem.
Edited by: user13413948 on 15-feb-2012 15:37
Edited by: user13413948 on 15-feb-2012 15:38

Io exception: The Network Adapter could not establish the connection..
I'd check in tools->embedded oc4j server preferences (current workspace app / data sources) and do a refresh now.
Next, make sure your app module config files reference the right connection by right clicking the app module and selecting configuration. lastly, make sure the project points to the right database connection by right clicking project -> properties, business components.

Auto-Commit and Pooled JDBC Connections

Forum Members,
If I am using Oracle Pooled JDBC Connections in the OC4J container is auto-commit set to "true" by default?
If I set auto-commit to "false" and then close the logical connection, when that connection is handed out again on a later call to getConnection(), is auto-commit automatically set back to "true"?
Thanks,
Richard

Richard,
Pardon me if I am stating the obvious, but you could test that in your code by invoking the getAutoCommit() method in interface java.sql.Connection.
My experience (with OC4J stand-alone versions up to -- and including -- 10.1.2) is that the behaviour depends on which data source you have configured. For example, if you have defined an "ejb-location" attribute in your "data-sources.xml" file, and you use that as your JNDI lookup for your data source, then OC4J handles transactions and you shouldn't deal with "auto-commit" at all. See the following post for more details:
Re: OC4J 10.1.3 Preview 4 - Global transaction active
But if you have defined a "location" attribute and use that, then you do need to handle transactions explicitly.
Hope this helps.
Good Luck,
Avi.

Xa-problems when releasing jdbc connection

We have a very strange problem with our WL setup.
Weblogic 8.1.4 (2 cluster nodes)
Oracle 9i stand alone db (although tested on RAC with 2 nodes)
The application architecture is quite complicated, with several EJB-applications that communicate via JMS and RMI. Everything (except logging) runs under xa-transactions that span multiple applications. We use both xa (for everything but logging) and non-xa jdbc connection pools (Oracle thin driver).
When we release a jdbc connection then the following node manager log entry is written:
<Mar 13, 2006 11:11:02 AM UTC> <Error> <JDBC> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "myPoolXA" failed with exception: "oracle.jdbc.xa.OracleXAException".>
<Mar 13, 2006 11:11:02 AM UTC> <Error> <JDBC> <BEA-001035> <The following error has occured: XA operation failed : java.lang.NullPointerException
at weblogic.jdbc.wrapper.VendorXAResource.rollback(VendorXAResource.java:78)
at weblogic.jdbc.jta.DataSource.rollback(DataSource.java:1047)
at weblogic.transaction.internal.XAServerResourceInfo.rollback(XAServerResourceInfo.java:1358)
at weblogic.transaction.internal.XAServerResourceInfo.rollback(XAServerResourceInfo.java:687)
at weblogic.transaction.internal.ServerSCInfo.startRollback(ServerSCInfo.java:729)
at weblogic.transaction.internal.ServerTransactionImpl.localRollback(ServerTransactionImpl.java:1909)
at weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTransactionImpl.java:2592)
at weblogic.transaction.internal.ServerTransactionImpl.internalRollback(ServerTransactionImpl.java:385)
at weblogic.transaction.internal.ServerTransactionImpl.rollback(ServerTransactionImpl.java:364)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:279)
at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.java:140)
at com.xx.myapp.ejb.MessageMgmt_s1i1u8_EOImpl.processMessage(MessageMgmt_s1i1u8_EOImpl.java:56)
at com.xx.myapp.ejb.MessageMgmt_s1i1u8_EOImpl_CBV.processMessage(Unknown Source)
at com.xx.myapp.ejb.TextMessageReceiverBean.onMessage(TextMessageReceiverBean.java:120)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
As we understand the message this means that the jdbc resource wrapper crashes with a NPE.
Are there any hints on this situation ?
Regards
Nikolaus Rumm

Additional information:
We use Hibernate as the persistence layer. The problem arises when the application detects a business problem and calls setRollbackOnly() on the session bean's ejb context, followed by a "throw ApplicationException" (extends java.lang.Exception).
When we use unchecked exceptions for business exceptions (which violates the EJB spec) everything works fine.

Errors using weblogic sql driver: "No JDBC connection can be made because the transaction state is marked rollback"

One of our customers starts to encounter this error message recently.
We checked our log files. It seems that the error happens when
to obtain a jdbc connection. Have anyone seen similar problems
and knows how to fix it? thanks in advance.
We are using weblogic server 6.1sp2, and weblogic sql type 4 driver.
The functions that invoke the jdbc calls are stateless session bean
methods with their transaction attributes marked as Required.
There is no nested calls of these methods.
A partial stack trace we obtained is as following:
java.sql.SQLException: No JDBC connection can be made
because the transaction state is
Marked Rollback
 at weblogic.jdbc.jts.Connection.getOrCreateConnection(Connection.java:586)
 at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:115)
 at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
 at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
lixin

Joseph Weinstein <[email protected]> wrote:
>
>
YuanHui Liu wrote:
Joe,
We got the exact same error message. The error came after we got theJDBC connection,
and trying to create statement off it.
It occurs intermitently when we are running another standalone JAVAapp to do
some end of day work, which results in the DB Server being very busy(90+%CPU
usage) for about 5 minutes. We see a surge of requests to the WLSJDBC Connection
pool. This would sometimes result in all our subsequent DB requeststo fail and
lead to a crash.
We are using WLS6.0SP1. I do not think there's a 30 seconds wait leadingto a
connection timeout that caused this(rather it is the end effect).
Can you give us a more detailed explanation? Is there a miscommunicationbetween
our DB(Sybase12) and WLS?Hi. It looks to you like it's after you get the connection, but really
it's when the server is
gettng the pool connection. For performance/synchronization reasons we
do a clever
delay: When your code asks for a pool connection we quickly give you
the pool wrapper,
but we delay actually reserving the real underlying DBMS connection until
your first
real need for a connection, at your first JDBC call, such as createStatement()
etc.
It is while waiting for a pool connection long enough for the transaction
coordinator
to have timed you out before you ever get a chance. It's nothing to do
with the
DBMS or even JDBC, I believe. I think the weblogic server either has
too few execute-threads
and/or too few CPU cycles to do the work load.
Okay, so there's a lazy initialization of the connection.
From reading our log I believe our failur is immediate rather
than waiting for 30+ seconds(the default setting) from the DB,
the timeout occurred later as a result. At the time either because the DB Server
is very busy.
Since we are running WLS6.0 we have only one connection pool,
we have defined a max of 150 threads in the pool. While this
is happening the DB Server is being pinned by an overnight job,
but the WLS Server is not busy at all. The DB and WLS resides
on different physical boxes.
We also have a thread dump from the WLS console when we rebooted the server, it
showed that we are hanging on to the thread & jdbc
connections after these exceptions has occurred instead of releasing them, note
"16083"(~4.5 hours) seconds has passed:
142 116222 Retry rollback request for tx: 'transaction=(IdHash=2963855,Name =
[EJB UserManagerBeanImpl.signalICUserServletHeartBeat()],Xid=30643:8f3838f3709bf53d,Status=Rolling
Back. [Reason = Unknown],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
begin=16083,seconds left=10,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=server),SCInfo[server]=(state=active),properties=({weblogic.jdbc=t3://159.55.158.25:8005,
weblogic.transaction.name=[EJB UserManagerBeanImpl.signalICUserServletHeartBeat()]}))'
Scheduled Trigger
So I would argue this problem actually chewed up resources on the WLS server.
-Yuanhui Liu
>>
>>
Thanks.
-YuanHui Liu
Joseph Weinstein <[email protected]> wrote:
lixin wrote:
One of our customers starts to encounter this error message recently.
We checked our log files. It seems that the error happens when
to obtain a jdbc connection. Have anyone seen similar problems
and knows how to fix it? thanks in advance.
We are using weblogic server 6.1sp2, and weblogic sql type 4 driver.
The functions that invoke the jdbc calls are stateless session bean
methods with their transaction attributes marked as Required.
There is no nested calls of these methods.
A partial stack trace we obtained is as following:
java.sql.SQLException: No JDBC connection can be made
because the transaction state is
Marked Rollback
at weblogic.jdbc.jts.Connection.getOrCreateConnection(Connection.java:586)Hi. This sounds like a JVM thread starvation issue, and/or a server
load
issue. What is
happening is that the transaction is started, and times out beforethe
SSB even gets to
the first JDBC work. I would first verify that the customer is using
the very latest JVM
available for the machine.
Joe Weinstein
at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:115)
at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
lixin

JDBC connection in EJB

Similar Messages

Maybe you are looking for