JDBC transactions in EJB 3.0

We have an EJB 3.0 method that call some jdbc DAO methods. This DAO methods called from controller (servlet) works fine, but when called from EJB method raise the following exception:
"java.sql.SQLException: Cannot call Connection.commit in distributed transaction. Transaction Manager will commit the resource manager when the distributed transaction is committed."
I think it is a JTA related error. I don't want to use JTA because I can't modify DAO (its a third party library).
I've tried annotation @TransactionAttribute(value=SUPPORTS) in the EJB method without success.
There is anyway to say EJB 3.0 not use JTA?
Thank's

Frank, yes, I can modify if it is necessary the datasource but, how can I say in the xxxx-jdbc.xml not to use JTA transactions when this data source is called inside a ejb 3.0 method?
I'm using Jdev11g and the integrated Web Logic Server.
Thank's

Similar Messages

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

UserTransaction or JDBC transaction

Hi,
please give suggestions...
We are using a application server with connection pooling
jsp and servlets are used in project
for transactions Is userTransaction is better or JDBC transaction is better
userTransaction may be implemented like this
try
getUserTransaction
transaction.begin
execute queries
transaction.commit
catch()
transaction.setRollbackOnly
JDBC Transaction may be implemented like this
connection.autoCommit=false
try
execute queries
connection.commit
catch()
connection.rollback
which is better for scalability and performance when we have to use transactins
in jsp/servlets
regards

Hi,
You are talking about using programmatic transactions in J2EE applications.
When developing J2EE applications, you are recommended to use the transaction mechanism provided by the application servers.
Sometimes, JDBC transaction can undertake the whole task. However, using JTA (Java Transaction APIs) is the better choice.
Especially when you are going to develop a lot of components (JavaBeans/ EJBs).
Imangine if a transaction is to be finished after the coroperation of serveral objects(JavaBean/ EJB instances).
How can you control the begining and the ending of the transaction by puting codes in these programs?
But it is very easy to input JTA codes (just like userTransaction etc.) to implement it.
Therefore, to use JTA is more convinient.
Additionally, J2EE specifications recommend to use declarative transactions in EJBs. Thus transaction management could be more flexible.
Good luck.
Gary Wang
Developer Technical Support
Sun Microsystems
http://www.sun.com/developers/support/

Setting JDBC Transaction Isolation

https://community.jboss.org/wiki/ConfigDataSources
As explained in the above URL, with JBoss, you can set the JDBC transaction isolation level in the xml file that contains the JDBC connection information.
I've been doing some googling, but I'm not clear on how this can be done with WebLogic. Is there some kind of external file where you can set the JDBC transaction isolation level as with JBoss, or is this some kind of change that can only be made in the application code or in some file contained within the application archive file (ear, war, etc.)?

You can set the isolation in the deployment override weblogic-ejb-jar.xml
- http://docs.oracle.com/cd/E21764_01/web.1111/e13719/ejb_jar_ref.htm#i1116237
- http://docs.oracle.com/cd/E21764_01/web.1111/e13719/ejb_jar_ref.htm#i1219612

Transaction in ejb

hi,
I am trying to do transaction using ejb.My bean has two method.The transaction mode of the bean is TX_REQUIRED and is stateful.I am using the jts driver and this is the code i have written.
public void addemp()throws RemoteException
try
usertran.begin();
Connection con=DriverManager.getConnection("jdbc:oracle:jts8:@DADTest");
Statement stmt=con.createStatement();
stmt.executeUpdate("insert into emp1 values(" + "'abdul',23)");
adddept();
usertran.commit();
con.close();
catch(SQLException e)
e.printStackTrace();
public void adddept()throws RemoteException
try
Connection con=DriverManager.getConnection("jdbc:oracle:jts8:@DADTest");
Statement stmt=con.createStatement();
stmt.executeUpdate("insert into dept2 values(" + "23,'sales','mumbai')");
con.close();
catch(SQLException e)
e.printStackTrace();
when i run this bean it gives me the following error:
Creating a new EJB instance
oracle.oas.container.runtime.CreateException: oracle.oas.container.runtime.CreateException: java.lang.IllegalStateException: Mode TX_BEAN_MANAGED required Mode = TX_SUPPORTS
javax.ejb.CreateException: oracle.oas.container.runtime.CreateException: oracle.oas.container.runtime.CreateException: java.lang.IllegalStateException: Mode TX_BEAN_MANAGED required Mode = TX_SUPPORTS
if any one of you can help me on this issue it wil be very grateful.
thanks in advance.

It seems like I need to inform my colleages
that this 200,000-update process is a business logic
problem.This might help a great bit.
>
But what if this is a real life needed process ? We
already have a good team of architects and
developers.This statement is questionable. There is a fundamental problem with "one transaction that has more than 200,000 update processes".
Aside, which also indicates the skill level of this "good team of architects and developers", if it really exists.
Your group should rethink what is considered a transaction and really analyze the reasons why so many updates need to occur as one batch.
It would be fantastical if this system could maintain 200,000 live Entity EJB at any one point in time. Either way, you need to rethink, from business terms, what a transaction should be.
This sounds like a data bulk upload process. There may be no business analysts involved to guide you. You should refer to the "good team" for their advice in addition to this forum. They should be able to provide you with good direction.

How to start and finish a transaction using EJB 3.0 in JDeveloper

Hello everybody!
Does anybody can explain how to start and finish a transaction using EJB 3.0. I need to start a transaction insert some information in some tables and if everything was fine commit the information.
I put the annotation @TransactionManagement(TransactionManagementType.BEAN) in my session bean and @Resource SessionContext ejbContext; but I don't what anything else I have to do.
Any help will be appreciate.

I tryied to use in the client the statement EntityTransaction transaction = myBean.getTransact(); but I receive the EJBException: Cannot use resource level transactions with a container managed EntityManager
I just need to start a transaction something like this: transaction.begin(); and finish the transaction, something like this: transaction.commit();
Does anybody can help?

A jdbc transaction error occur

Hi Everybody
A jdbc transaction error occur when I deploy the application on the server .
Below is the stack trace
#SAP J2EE Engine JTA Transaction : [03bfffffffd3a000ffffffc0]####Application [13]##0#0#Error#1#/System/Audit#Java###Exception #1#com.sap.engine.services.dbpool.exceptions.BaseSQLException: Cannot commit transaction from this connection of "YTSQLS2K" DataSource. This resource participates in a local or distributed transaction.
#SAP J2EE Engine JTA Transaction : [03bfffffffd3a000ffffffc0]####Application [13]##0#0#Error#1#/System/Audit#Java###Exception #1#com.sap.engine.services.dbpool.exceptions.BaseSQLException: Cannot initiate transaction from a connection of "YTSQLS2K" DataSource. Local or distributed transaction has already started.
#SAP J2EE Engine JTA Transaction : [03bfffffffd3a000ffffffc0]####Application [13]##0#0#Error#1#/System/Audit#Java###Exception #1#com.sap.engine.services.dbpool.exceptions.BaseSQLException: Cannot commit transaction from this connection of "YTSQLS2K" DataSource. This resource participates in a local or distributed transaction.
Any idea about it
I use the jdbc version in datasource <jdbc-1.x>
is there a need to replace it with <jdbc-2.0>
Thank You
Syed Saifuddin

Hibernate allows you to choose transaction manager. As Nikolay pointed out, in a JEE envirnment it's prefferable to use JTA transactions. All you need to do is to configure hibernate to use a JTA transaction manager. It is all written in the Hibernate documentations. See
http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#configuration-j2ee
and
http://www.hibernate.org/42.html#A5 .
The relevant properties that need to be set in the configuration are:
hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory
and
hibernate.transaction.manager_lookup_class=<Class that knows how to lookup>
You need to implement a class that knows how to lookup user transaction in SAP J2EE Egnine.
The class must extend org.hibernate.transaction.JNDITransactionManagerLookup and only override its abstract method getName (simply returning the lookup string). Then provide the fully qualified name as value of the property and make sure that Hibernate can load the class.
That should work.
HTH
-Georgi
Message was edited by:
Georgi Pavlov

Default Transaction for EJB

Hi All,
Could you please let me know what is the default transactions for EJB 2.0?
In case of business methods of stateless session beans.
Thanks

I believe the default propagation is REQUIRED and the default isolation level for most databases is READ COMMITTED. Or were you looking for something else?
http://www.ibm.com/developerworks/java/library/j-jtp0514.html
- Saish

Error javax.transaction.TransactionRolledbackException: EJB Exception

Good afternoon, appeared to me the following error, anyone know what it is?
oracle.iam.connectors.common.dao.OIMUtil : OIMUtil() : EJB Exception: : javax.transaction.TransactionRolledbackException: EJB Exception

Hi,
Thanks for the info..But I can't seem to figure out what wrong in my SP.
This is my stored proc. and line no.20 pointing to ORA-06152 is the insert statement..
Can someone help me out please!!
CREATE OR REPLACE PROCEDURE "DBS1"."INS_EXPENSE"
( expense_type in VARCHAR2
, party_payed_to in VARCHAR2
, expense_amount in NUMBER
, bill_date in DATE
, booked_date in DATE
, payed_from_acc in VARCHAR2
, payed_to_acc in VARCHAR2
, payment_mode in VARCHAR2
, status in VARCHAR2
, comment in VARCHAR2
, entry_userid in VARCHAR2
, last_chg_userid in VARCHAR2
, expense_no out NUMBER
IS
BEGIN
select max(EXPENSE_NO) into expense_no from DBS1.EXPENSE;
expense_no := expense_no + 1;
insert into DBS1.EXPENSE (EXPENSE_NO,EXPENSE_TYPE,PARTY_PAYED_TO
,EXPENSE_AMOUNT,BILL_DATE,BOOKED_DATE,PAYED_FROM_ACC,PAYED_TO_ACC
,PAYMENT_MODE,STATUS,COMMENT,ENTRY_TIMESTAMP,ENTRY_USERID
,LAST_CHANGE_TIMESTAMP,LAST_CHANGE_USERID) VALUES
(expense_no,expense_type,party_payed_to,expense_amount,TO_DATE(bill_date,'yyyy-mm-dd')
,TO_DATE(booked_date,'yyyy-mm-dd'),payed_from_acc,payed_to_acc,payment_mode,status
,comment,SYSDATE,entry_userid,SYSDATE,last_chg_userid);
END INS_EXPENSE;
TIA

Calling Glassfish jdbc Datasorce in EJB 3.0 with @Resource annotation.

I tried EJB 3.0 with netbeans and glassfish and "{color:#ff0000}+_ORACLE_+{color}". I wanted to link the oracle database to GLASSFISH server and I followed the instructions.After I clicked 'ping' button, it displayed as *{color:#339966}'PING SUCCEED".{color}*
But I couldn't call my datasource from the eje stateless session bean with @Resource annotation.It resulted a dependency injection exception. Can some one tell me how to do this properly.
{color:#ff0000}Thanks in Advance!!!!{color}

Frank, yes, I can modify if it is necessary the datasource but, how can I say in the xxxx-jdbc.xml not to use JTA transactions when this data source is called inside a ejb 3.0 method?
I'm using Jdev11g and the integrated Web Logic Server.
Thank's

JDBC Transaction is no longer active - status: 'Marked rollback'

I'm getting the folowing issue, we are not seeing this issue if we recycle the WLS
Using WLS V10.3.3
Can any one suggest on this issue, how to reslove this
85417.772: [Full GC [PSYoungGen: 117504K->0K(234880K)] [PSOldGen: 662564K->665699K(700416K)] 780068K->665699K(935296K) [PSPermGen: 133284K->132438K(225280K)], 30.2876423 secs] [Times: user=31.23 sys=0.68, real=30.32 secs]
java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 39 seconds
BEA1-600C65F8B23E363DFDF0]'. No further JDBC access is allowed within this transaction.
at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:193)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:209)
at weblogic.jdbc.wrapper.ResultSet.preInvocationHandler(ResultSet.java:99)
at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_OracleResultSetImpl.next(Unknown Source)
at com.vzw.pos.cmw.ejb.service.UserProfileService.getNewUserId(Unknown Source)
at com.vzw.pos.cmw.ejb.utils.CMWEjbUtil.createUserProfileVO(Unknown Source)
at com.vzw.pos.cmw.ejb.utils.CMWEjbUtil.createRosterVO(Unknown Source)
at com.vzw.pos.cmw.ejb.service.AdministrationBean.getRostersByUserId(Unknown Source)
at com.vzw.pos.cmw.ejb.service.Administration_ujnwz8_ELOImpl.__WL_invoke(Unknown Source)
at weblogic.ejb.container.internal.SessionLocalMethodInvoker.invoke(SessionLocalMethodInvoker.java:39)
at com.vzw.pos.cmw.ejb.service.Administration_ujnwz8_ELOImpl.getRostersByUserId(Unknown Source)
at com.vzw.pos.cmw.action.CMWTopFrameAction.setUserRoleInSession(Unknown Source)
at com.vzw.pos.cmw.action.CMWTopFrameAction.changeLocation(Unknown Source)
at sun.reflect.GeneratedMethodAccessor190.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:280)
at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:216)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at com.vzw.pos.cmw.filters.CMWFilter.doFilter(Unknown Source)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3710)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3676)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2272)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2178)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
<Aug 23, 2013 10:41:53 AM EDT> <Warning> <Socket> <BEA-000450> <Socket 298 internal data record unavailable (probable closure due idle timeout), event received -32>
<Aug 23, 2013 10:41:53 AM EDT> <Warning> <Socket> <BEA-000450> <Socket 286 internal data record unavailable (probable closure due idle timeout), event received -32>
<Aug 23, 2013 10:41:56 AM EDT> <Warning> <Socket> <BEA-000450> <Socket 299 internal data record unavailable (probable closure due idle timeout), event received -32>
<Aug 23, 2013 10:42:51 AM EDT> <Warning> <Socket> <BEA-000450> <Socket 286 internal data record unavailable (probable closure due idle timeout), event received -32>

Here is DS configuration
Initial Capacity:                  75
Maximum Capacity:                  75
Capacity Increment:                    1
Seconds to trust an idle pool connection:     10
Shrink Frequency:                    900
Enable Connection Leak Profiling:          False
Enable Connection Profiling:               False
Test Frequency:                         120 seconds
Test Connections on Reserve:               True
Connection Reserve Timeout:               10 seconds
Connection Creation Retry Frequency:         1
Inactive Connection Timeout:               60 second
Maximum Waiting for Connection:               2147483647
Statment Cache Type:     LRU
Statment Cache Size:     10
Connection Creation Relay Frequency:      1
Remove Infected Connections Enabled:      True
Wrap Data types:     True
Ignore In-use connections:     True

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<br>");
javax.naming.InitialContext ctx = new javax.naming.InitialContext();
ds = (javax.sql.DataSource) ctx.lookup("jdbc/MyDataSource");
out.println("Getting connection<br>");
con = ds.getConnection();
con.close();
} catch (Exception e) {
e.printStackTrace(out);
out.println("Done<br>");
Feedback
Your e-mail:
Rate this article:
Very useful Somewhat useful Not bad Needs many corrections
Comments:

Transaction & non-EJB objects (helper)

hi i have a question about transactional behavior of non-EJB objects. i'm
          using
          weblogic 6.0 sp1 with ejb 2.0.
          say i have a session bean which starts a container managed transaction. and
          it calls
          out to helper class A(non-EJB), and that helper class A get a connection and
          update
          some tables. after A returns, session bean calls helper class B(non-EJB) in
          the
          same transaction. B is supposed to update some other tables but it throw an
          user
          exception. would the transaction in the session bean be rolled back? would
          it
          also roll back the changes made by helper class A?
          thanks for any help,
          z


Thanks Rob!
          "Rob Woollen" <[email protected]> wrote in message
          news:[email protected]...
          > Ziqiang Xu wrote:
          >
          > > hi i have a question about transactional behavior of non-EJB objects.
          i'm
          > > using
          > > weblogic 6.0 sp1 with ejb 2.0.
          > >
          > > say i have a session bean which starts a container managed transaction.
          and
          > > it calls
          > > out to helper class A(non-EJB), and that helper class A get a connection
          and
          > > update
          > > some tables.
          >
          > You must get the JDBC connection from a TxDataSource.
          >
          > > after A returns, session bean calls helper class B(non-EJB) in
          > > the
          > > same transaction. B is supposed to update some other tables but it
          throw an
          > > user
          > > exception. would the transaction in the session bean be rolled back?
          >
          > Merely throwing an exception from a helper class will not rollback the
          > transaction.
          >
          > Within an EJB, the best way to rollback a tx is to use the
          > EJBContext.setRollbackOnly method.
          >
          > So you could do something like this:
          >
          > session_bean_method() {
          >
          > try {
          > B.foo();
          > } catch (MyException e) {
          > ctx.setRollbackOnly();
          > throw e;
          > }
          >
          > }
          >
          > > would
          > > it
          > > also roll back the changes made by helper class A?
          > >
          >
          > If they are all within a single transaction, then yes. As I mentioned
          before,
          > make sure that you use a TxDataSource for all of your JDBC Connections.
          >
          > -- Rob
          >
          > >
          > > thanks for any help,
          > >
          > > z
          >

JDBInsight 2.0 Released - True JDBC Transaction Analysis !!!

Check out the new product release and revised documentation at:
http://www.jinspired.com/products/jdbinsight/downloads/index.html
PRESS RELEASE
=============
DUBLIN, IRELAND - 29th October, 2003 - JInspired (www.jinspired.com), a leader
in J2EE(tm) transaction analysis, today announced JDBInsight 2.0, the next generation
of J2EE performance management products from JInspired.
JDBInsight is the first product to effectively integrate Java profiling information
with JDBC/SQL transaction analysis. Version 2.0 has numerous features derived
from its support of the Java VM Profiling Interface(JVMPI) such as Java call stack
analysis, cpu, blocking and waiting measurements at the transaction path level.
Clock measurements are adjusted for blocking, waiting and gc pauses. New features
in this release
- New console user interface: Many new informative visualizations of J2EE transactions
and performance execution profiles have been added. Including call stack graphs,
entry point tree maps, sequence diagrams, call stack and transaction transcripts.
Additional views included allow for navigation of the performance profile via
database table or column, Java package, class, or method, technology classification,
SQL tokens, or transaction entry points.
- Java call stack classification engine: Developers, testers, database and J2EE
server administrators can now better understand the interaction of various Java
enterprise technologies with corporate databases. Classifications are available
for Java enterprise technologies such as EJB, Hibernate, JDO, JMS, JSP, Servlets,
JTS, JDBC, and Struts.
- Terminal services: The terminal services add-on provides a quick and easy way
to communicate with multiple servers without having to use a graphical user interface.
This facilitates the streamlined connection, activation and deactivation of profiles
on local or remote servers with the ability to control multiple servers from a
single terminal. The terminal environment provides a powerful environment to create
and schedule snapshot information, in order to monitor servers at regular intervals,
with the ability to store and retrieve snapshots from any mounted drive, as well
as providing a rich set of commands, that can be executed from saved scripts,
to assist in analysis of this highly detailed profile data.
- Transaction demarcations: JDBInsight 2.0 is the first performance management
product to have the ability to detect and present resource transaction demarcations
- allowing visual sub-transaction identification.
- Resource Management: JDBInsight keeps counters representing objects states for
each JDBC interception point create a resource object. When a JDBC resource changes
state the allocation site counters are updated. This helps to pinpoint source
code locations where resource objects are created and not closed properly or freed
from memory. Because an interception is a combination of call stack and SQL the
view caters for generic J2EE application frameworks which create objects based
on application parameters and callers.
- Xml export: Various statistical measurements can be viewed in Xml format and
copied into applications for custom report generation.
- Server options: Additional system properties to customize the small amount of
overhead added during runs.
About JDBInsight
JDBInsight is an innovative enterprise development product, aimed at simplifying
the performance tuning and testing of J2EE(tm) applications, which access data
through the Java Database Connectivity (JDBC(tm)) API. JDBInsight analyses the
access of enterprise data by J2EE(tm) client-, web-, and bean containers. The
analysis can encompass transaction executions, from multiple J2EE(tm) containers.
JDBInsight captures timing and execution information for enterprise data accessed
by Servlets, JavaServer Pages, Session- and Entity Beans using JDBC(tm) or an
Entity Bean using a container's persistence engine. JDBInsight can also profile
non-J2EE applications that access enterprise data through the JDBC(tm) API.
What distinguishes JDBInsight from other profiling and performance management
tools on the market is that JDBInsight provides analysis from a sequence perspective
instead of simply showing a call tree. Inefficiencies in J2EE applications occur
mainly at the transaction level such as repeating the execution of a particular
SQL locally and globally. JDBInsight facilitates the recognition of database interaction
patterns that exhibit inefficiencies when viewed in terms of the sequential execution
of a business and/or resource transaction.
About JInspired
JInspired located in Ireland, delivers JDBInsight, a comprehensive solution for
Application Performance Tuning and Testing that focuses directly on early identification
within the development and testing lifecycle. Jinspired offers sophisticated analytical
tools, that capture transactional behaviour and performance timing information,
across multiple containers in a single console, and presents this information
intuitively to the user "Visualizing the Invisible".

Check out the new product release and revised documentation at:
http://www.jinspired.com/products/jdbinsight/downloads/index.html
PRESS RELEASE
=============
DUBLIN, IRELAND - 29th October, 2003 - JInspired (www.jinspired.com), a leader
in J2EE(tm) transaction analysis, today announced JDBInsight 2.0, the next generation
of J2EE performance management products from JInspired.
JDBInsight is the first product to effectively integrate Java profiling information
with JDBC/SQL transaction analysis. Version 2.0 has numerous features derived
from its support of the Java VM Profiling Interface(JVMPI) such as Java call stack
analysis, cpu, blocking and waiting measurements at the transaction path level.
Clock measurements are adjusted for blocking, waiting and gc pauses. New features
in this release
- New console user interface: Many new informative visualizations of J2EE transactions
and performance execution profiles have been added. Including call stack graphs,
entry point tree maps, sequence diagrams, call stack and transaction transcripts.
Additional views included allow for navigation of the performance profile via
database table or column, Java package, class, or method, technology classification,
SQL tokens, or transaction entry points.
- Java call stack classification engine: Developers, testers, database and J2EE
server administrators can now better understand the interaction of various Java
enterprise technologies with corporate databases. Classifications are available
for Java enterprise technologies such as EJB, Hibernate, JDO, JMS, JSP, Servlets,
JTS, JDBC, and Struts.
- Terminal services: The terminal services add-on provides a quick and easy way
to communicate with multiple servers without having to use a graphical user interface.
This facilitates the streamlined connection, activation and deactivation of profiles
on local or remote servers with the ability to control multiple servers from a
single terminal. The terminal environment provides a powerful environment to create
and schedule snapshot information, in order to monitor servers at regular intervals,
with the ability to store and retrieve snapshots from any mounted drive, as well
as providing a rich set of commands, that can be executed from saved scripts,
to assist in analysis of this highly detailed profile data.
- Transaction demarcations: JDBInsight 2.0 is the first performance management
product to have the ability to detect and present resource transaction demarcations
- allowing visual sub-transaction identification.
- Resource Management: JDBInsight keeps counters representing objects states for
each JDBC interception point create a resource object. When a JDBC resource changes
state the allocation site counters are updated. This helps to pinpoint source
code locations where resource objects are created and not closed properly or freed
from memory. Because an interception is a combination of call stack and SQL the
view caters for generic J2EE application frameworks which create objects based
on application parameters and callers.
- Xml export: Various statistical measurements can be viewed in Xml format and
copied into applications for custom report generation.
- Server options: Additional system properties to customize the small amount of
overhead added during runs.
About JDBInsight
JDBInsight is an innovative enterprise development product, aimed at simplifying
the performance tuning and testing of J2EE(tm) applications, which access data
through the Java Database Connectivity (JDBC(tm)) API. JDBInsight analyses the
access of enterprise data by J2EE(tm) client-, web-, and bean containers. The
analysis can encompass transaction executions, from multiple J2EE(tm) containers.
JDBInsight captures timing and execution information for enterprise data accessed
by Servlets, JavaServer Pages, Session- and Entity Beans using JDBC(tm) or an
Entity Bean using a container's persistence engine. JDBInsight can also profile
non-J2EE applications that access enterprise data through the JDBC(tm) API.
What distinguishes JDBInsight from other profiling and performance management
tools on the market is that JDBInsight provides analysis from a sequence perspective
instead of simply showing a call tree. Inefficiencies in J2EE applications occur
mainly at the transaction level such as repeating the execution of a particular
SQL locally and globally. JDBInsight facilitates the recognition of database interaction
patterns that exhibit inefficiencies when viewed in terms of the sequential execution
of a business and/or resource transaction.
About JInspired
JInspired located in Ireland, delivers JDBInsight, a comprehensive solution for
Application Performance Tuning and Testing that focuses directly on early identification
within the development and testing lifecycle. Jinspired offers sophisticated analytical
tools, that capture transactional behaviour and performance timing information,
across multiple containers in a single console, and presents this information
intuitively to the user "Visualizing the Invisible".

JDBC transactions in EJB 3.0

Similar Messages

Maybe you are looking for