Rollback a transaction in a session bean BMP?
The following code would work correctly if executed in a stateless session bean BMP?
InitialContext ic = new InitialContext();
javax.sql.DataSource dataSource = (javax.sql.DataSource) ic.lookup("java:comp/env/jdbc/OracleDS");
Connection conn = dataSource.getConnection();
conn.setAutoCommit(false);
Statement stmt = conn.createStatement("UPDATE TABLE_A SET NAME = 'Duke' WHERE ID = 7");
stmt.executeUpdate();
if (someCondition) {
conn.commit();
} else {
conn.rollback();
My question:
It�s possible to rollback a transaction using rollback() from Connection class in a stateless
session bean BMP?
Dear JDC member:
With EJB, you can gain the benefit of transactions without performing any transaction programming. That is, your enterprise beans never explicitly issue a begin, commit, or abort statement. The container performs it to you. But you have to tell the container how to do it. As you might know, the deploment descriptor is the place for it.
But nothing prevent you to do do programmatic transaction as you want.. For that case you have to know JTA (Java Transaction API) and more.
Suppose the transaction aborts, you have to throw an exception back to the client or try it again. The issue here is with stateless sesssion beans, there is no in-memory conversational state. You might think to implement javax.ejb.SessionSynchronization interface with your business methods....
You see there is a lot to know. You can take care of transactions in the client code, but it is a bad design.
You have to understand today most application servers (Websphere, Weblogic...) are designed to minimize those issues in order to make developers' tasks easier. The container takes care of transactions.
Be careful when you write stateless session beans BMP (BMP are for entiti beans)
Regards,
Armand Komenan
Similar Messages
-
Handling Transaction in Stateful Session Bean
I wrote a public method like public void doTransaction()
it will call 2 private method, like: methodA and methodB
Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?Ok... Here it goes...
You can do it in the following manner.
As you said you have got 2 private methods doing d/b updates and these are called from a public method.
Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
The problem you are dealing with can typically very well handled by writing bean managed transaction.
Hope this helps. If you need anymore clarity on my solution, please let me know.
-amit -
Transaction using stateful session bean.
All,
I was implementing "Transaction" part using statefull session(trying to understand how transaction work).
I created a Statefull session bean, here in one method create 2 sql queries
query1:update Employees set LastName='newname' where EmployeeID = 9
query2:update Customers set CompanyName = 'newname Inc.' ContactName = 'Maria Anders'
"query1" works fine, but "query2" is not correct(syntax error) hence will not be executed. This will throw a SQLException.
According to EJBspec, rollback will happen if there is a system exception. And I guess SQLException is systemexception.
But when I query "Employees" table, I get the data updated through the "query1".
What I was excepting was the first query which was executed should have rolled back because the second query has thrown a SQLException.
I tried using ContainerManaged transaction and BeanManaged transaction.
But in both cases transaction is not getting rolled back.
I have tried with REQUIRED and REQUIRESNEW attributes for container managed transactions with Isolation level as Read Commited.
Is my understanding correct?
TIA,
VijayTried using Bean managed transactions but with the same result. Given below is the sample code.
UserTransaction uts = null;
try {
uts = (UserTransaction)(ctx.getUserTransaction());
uts.begin();
Connection con = null;
con = getCountConnection();
PreparedStatement ps = con.prepareStatement(sqlselectUserId);
ps.executeUpdate();
PreparedStatement ps1 = con.prepareStatement(sqlselectUserDetails);
ps1.executeUpdate();
uts.commit();
catch(SQLException e) {
uts.rollback(); -
Rolling back the transaction from stateful session bean
Hi,
How can I mark the transaction to be rolled back in a stateful session bean implementation?.
Should I call setRollbackOnly method or throw a RemoteException or throw an EJBException, etc.?
the configuration is :
OC4J 9.0.4
Stateful session bean
Related method has transaction attribute - "Required"
thanks & regards.
ps : I couldn't find a related topic even if this has been discussed before (too many topics). if so, excuses.
Erdem.Tried using Bean managed transactions but with the same result. Given below is the sample code.
UserTransaction uts = null;
try {
uts = (UserTransaction)(ctx.getUserTransaction());
uts.begin();
Connection con = null;
con = getCountConnection();
PreparedStatement ps = con.prepareStatement(sqlselectUserId);
ps.executeUpdate();
PreparedStatement ps1 = con.prepareStatement(sqlselectUserDetails);
ps1.executeUpdate();
uts.commit();
catch(SQLException e) {
uts.rollback(); -
NON-transactional session bean access entity bean
We are currently profiling our product using Borland OptmizeIt tool, and we
found some interesting issues. Due to our design, we have many session beans which
are non transactional, and these session beans will access entity beans to do
the reading operations, such as getWeight, getRate, since it's read only, there
is no need to do transaction commit stuff which really takes time, this could
be seen through the profile. I know weblogic support readonly entity bean, but
it seems that it only has benefit on ejbLoad call, my test program shows that
weblogic still creates local transaction even I specified it as transaction not
supported, and Transaction.commit() will always be called in postInvoke(), from
the profile, we got that for a single method call, such as getRate(), 80% time
spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
using Exclusive lock, that's the reason that we use non-transactional session
bean to avoid dead lock problem.
ThanksSlava,
Thanks for the link, actually I read it before, and following is what I extracted
it from the doc:
<weblogic-doc>
Do not set db-is-shared to "false" if you set the entity bean's concurrency
strategy to the "Database" option. If you do, WebLogic Server will ignore the
db-is-shared setting.
</weblogic-doc>
Thanks
"Slava Imeshev" <[email protected]> wrote:
Hi Jinsong,
You may want to read this to get more detailed explanation
on db-is-shared (cache-between-transactions for 7.0):
http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
Let me know if you have any questions.
Regards,
Slava Imeshev
"Jinsong HU" <[email protected]> wrote in message
news:[email protected]...
Thanks.
But it's still not clear to me in db-is-shared setting, if I specifiedentity
lock as database lock, I assumed db-is-shared is useless, because foreach
new
transaction, entity bean will reload data anyway. Correct me if I amwrong.
Jinsong
"Slava Imeshev" <[email protected]> wrote:
Jinsong,
See my answers inline.
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
Hi Slava,
Thanks for your reply, actually, I agree with you, we need to
review
our db
schema and seperate business logic to avoid db lock. I can not say,guys,
we need
to change this and that, since it's a big application and developedsince
EJB1.0
spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
better aproach would be identifying the most critical piece and
make a surgery on it.
Following are questions in my mind:
(1) I think there should be many companies using weblogic serverto
develop
large enterprise applications, I am just wondering what's the maintransaction/lock
mechanism that is used? Transional session / database lock,
db-is-shared
entity
I can't say for the whole community, as for my experience the standard
usage patthern is session fasades calling Entity EJBs while having
Required TX attribute plus plain transacted JDBC calls for bulk
reads or inserts.
is the dominant one? It seems that if you speficy database lock,
the
db-is-shared
should be true, right?Basically it's not true. One will need db-is-shared only if thereare
changes
to the database done from outside of the app server.
(2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
load
once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
an application constantly reads new RO data, RO beans will be
constantly dropped from cache and new ones will be loaded.
You may want to looks at server console to see if there's a lot
of passivation for RO beans.
(3) For clustering part, have anyone use it in real enterpriseapplication?
My concern, since database lock is the only way to choose, how aboutthe
affect
of ejbLoad to performance, since most transactions are short live,if high
volume
transactions are in processing, I am just scared to death about
the
ejbLoad overhead.
ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
If ejbLoads take too much time, it could be a good idea to profile
used SQLs. Right index optimization can make huge difference.
Also you may want cosider using CMP beans to let weblogic
take care about load optimization.
(4) If using Optimization lock, all the ejbStore need to do
version
check
or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
use lighter isolation levels.
HTH,
Slava Imeshev
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
We are using Exclusive Lock for entity bean, because of we do
not
want
to
load
data in each new transaction. If we use Database lock, that means
we
dedicate
data access calls to database, if database deadlock happens,
it's
hard
to
detect,
while using Exclusive lock, we could detect this dead lock in
container
level.
The problem is, using Exclusive concurrency mode you serialize
access to data represented by the bean. This aproach has negative
effect on ablity of application to process concurrent requests.As
a
result the app may have performance problems under load.
Actually, at the beginnning, we did use database lock and usingtransactional
The fact that you had database deadlocking issues tells that
application logic / database schema may need some review.
Normally to avoid deadlocking it's good to group database
operations mixing in updattes and inserts into one place so
that db locking sequence is not spreaded in time. Moving to
forced serialized data access just hides design/implementation
problems.
session bean, but the database dead lock and frequent ejbLoad
really
kill
us,
so we decided to move to use Exclusive lock and to avoid dead
lock,
we
change
some session bean to non-transactional.Making session beans non-transactions makes container
creating short-living transactions for each call to entity bean
methods. It's a costly process and it puts additional load to
both container and database.
We could use ReadOnly lock for some entity beans, but since weblogicserver will
always create local transaction for entity bean, and we found
transaction
commit
is expensive, I am arguing why do we need create container leveltransaction for
read only bean.First, read-only beans still need to load data. Also, you may seeRO
beans
contanly loading data if db-is-shared set to true. Other reason
can
be
that
RO semantics is not applicable the data presented by RO bean (forinstance,
you have a reporting engine that constantly produces "RO" data,
while
application-consumer of that data retrieves only new data and neverasks
for "old" data). RO beans are good when there is a relatively stable
data
accessed repeatedly for read only access.
You may want to tell us more about your app, we may be of help.
Regards,
Slava Imeshev
I will post the performance data, let's see how costful
transaction.commit
is.
"Cameron Purdy" <[email protected]> wrote:
We are currently profiling our product using Borland
OptmizeIt
tool,
and we
found some interesting issues. Due to our design, we have
many
session
beans which
are non transactional, and these session beans will access
entity
beans
to
do
the reading operations, such as getWeight, getRate, since
it's
read
only,
there
is no need to do transaction commit stuff which really takes
time,
this
could
be seen through the profile. I know weblogic support readonly
entity
bean,
but
it seems that it only has benefit on ejbLoad call, my test
program
shows
that
weblogic still creates local transaction even I specified
it
as
transaction not
supported, and Transaction.commit() will always be called
in
postInvoke(),
from
the profile, we got that for a single method call, such as
getRate(),
80%
time
spent on postInvoke(), any suggestion on this? BTW, most of
our
entity
beans are
using Exclusive lock, that's the reason that we use
non-transactional
session
bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
understand of what WebLogic is doing.
First, you say "non transactional", but from your description
you
should
have those marked as tx REQUIRED to avoid multiple transactions
(since
non-transactional just means that the database operation becomesits
own
little transaction).
Second, you say you are using exclusive lock, which you shouldonly
use
if
you are absolutely sure that you need it, (and note that it
does
not
work in
a cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com/coherence.jsp
Tangosol Coherence: Clustered Replicated Cache for Weblogic
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
> -
Transaction management in BMP through Session bean(worked in J2EE RI)
This thing worked in the J2EE RI implementation, but not in OC4J.
Problem is:
In a BMP, if we throw an EJBException all the changes would be rolled back by the container, right? Or do we have to write code to do that?
I was reading through your reply in the list and I have a doubt regarding something regarding transaction handling in BMP entity beans. I am using the entity bean in a session bean and have two sql statements and one entity update. If one of the sql statements fails and the entity is updated , the changes are all rolled back, but in the case of the entity failure to update, the sql statement changes are not rolled back and I get an error saying
System/communication error: Transaction was rolled back: Error preparing bean in
stance: com.evermind.transaction.MarshallingXAException; nested exception is:
com.evermind.transaction.MarshallingXAException
The entity bean is throwing an EJBException back to the Session bean, but the session bean does not catch
it and continues forward as if nothing happened.
The funny thing is that the queries are placed like this
sqlinsert 1.......
entitybean update....
sqlinsert 2.....
So the flow becomes
sqlinsert 1 happens then sqlinsert 2 and only in the end does the entity bean throw the exception
any idea why this happens?
Can anyone help me on this. The BMP entity has persistence
<persistence-type>Bean</persistence-type>
Thanks
Kind Regards
Aby PhilipHi,
In general, whenever you manage your own transactions (such as in DAOs or in stored procedures) then you are limiting the ways that your code can be reused: your code will never be able to run in a client's transaction. This could mean trouble if you want to combine you software inside other beans that use it: when these other beans lead to a rollback then your DAO might still commit.
I would try to make the session bean use CMT, that is the most flexible if you are staying within the appserver.
Hope that helps,
Guy
http://www.atomikos.com -
Session Bean Transaction Rollback not working for RuntimeException
Hi,
I am calling a number of JDBC create/update statements within a method in a container managed transaction stateless session bean with transaction attribute set to required. I am running the bean within the embedded OC4J supplied with JDeveloper 10g (10.1.2). For each JDBC call, i connect to a datasource via JNDI containg a pool of connections pointing to an Oracle 10g database (standard J2EE)
If i throw a runtime exception within the method the transaction is NOT rolled back as it should be according to the EJB spec. However, if i setRollbackOnly() on the session bean SessionContext the transaction does roll back.
Has anybody experienced this before?
Is this an OC4J bug?
Thanks
DaveGenerally, for urgent issues it's best to open a SR with Oracle Support rather than posting to the forums.
enlist=dynamic didnt exist in 10.2.0.2.20, but does now. I can't recall what specific version it was introduced though.
enlist=false prevents enlistment in MSDTC transactions, so thats why it's not rolling back in that case.
"transaction branch length 90 is illegal" was a known issue on Vista, is that the OS you're using? It takes a two part fix, and It is resolved by
1) getting up to 10204 ODP (apply the 10204 rdbms patch to your client install)
2) applying SP1 for Vista
Hope it helps,
Greg -
Transaction management in stateless session beans.
Hi all,
I am using EJB 1.1.
I have a statless session bean that has two methods- A and B.
which does not involve any database interaction
like inserting/updating/deleting the data in the database.
The process flow is such the client always calls A first followed by the call to B.
I have the Transaction attribute set as TX_REQUIRED at the whole bean level.
Now my question is as follows:
Since it is a stateless bean, ejbCreate() is called for every method's invocation.
So does it mean that a new transaction is started for every method invocation?
Also since a transaction ends by commit/rollback.
The transation associated with the method A/B will never get completed as there is no commit/rollback involved in method implementation.
So how is this transaction ended?
Any more details about the transaction management in stateless session beans is highly appreciated.
Any input at the earliest is highly appreciated.
Thanks in advance.Since it is a stateless bean, ejbCreate() is called for every method's invocation.For stateless session bean , Create() is not delegated to the instance.
So does it mean that a new transaction is started for every method invocation?This depends opon the Tx attribute and sequence of calls. Since you have given Tx_required then if you call any method and there is no Tx context associated with client,then a new TX will be started by container othere wise it will execute in the same TX context as the calling client. Note that client can be jsp or other ejb method.
Also since a transaction ends by commit/rollback.
The transation associated with the method A/B will never get completed >as there is no commit/rollback involved in method implementation.
So how is this transaction ended?If you are using COntainer managed TX then Transaction handling like starting , ending etc is handled by the container. You need not worry about that.
Any more details about the transaction management in stateless session >beans is highly appreciated.
Any input at the earliest is highly appreciated.Some time back I had read the article on how the Transaction management done by container on IBM Site. I dont have URL , but you can search the site.
HTH
-Ashwani -
Transaction is not Rolling Back in Stateless Session Bean
Hi,
I am using UserTransaction in Stateless Session bean .
Transaction is not rolling back.
The following code is writen in stateless session bean. In UserTransaction i am
calling Two methods of another stateless session bean.
The problem is if doJob2() method fails, doJob1() method is rolling back. These
two methods consist of SQL statement with different Connection Object from TXDataSource.And
session bean(TestSession) is set to CMT, attribute as "Required".
try{
Context ictx=new InitialContext();
TestHome home=(TestHome)ictx.lookup("TestSession");
utx = sessionCtx.getUserTransaction();
utx.begin();
TestRemote remote=home.create();
remote.doJob1();
remote.doJob2();
utx.commit();
}catch(Exception e)
try{
utx.rollback();
}catch(Exception ex)
System.out.println("unable to rollback"+ex);
if any SQL Exception as occured in doJob2(), its calling method utx.rollback()
in catch block. but SQL statements executed thru. doJob1() are not rolling back.
what might be the reason?
thanks
Ranganath
Thanx Priscilla ,
Transaction is working.
ranganath
"Priscilla Fung" <[email protected]> wrote:
>
>In your ejb-jar.xml, you should specify <transaction-type> element to
>be "Container"
>for container-managed transaction. If you specified it to be "Bean" for
>bean-managed
>transaction, EJB ontainer will suspend the caller's transaction before
>starting
>a new transaction for your doJobX() methods. Thus, doJob1()nd doJob2()
>will be
>executing in different transactions, and thus rolling back doJob2()'s
>transaction
>will have no effect on work done and committed in doJob1()'s transaction.
>
>Regards,
>
>Priscilla
>
>
>"Ranganath" <[email protected]> wrote:
>>
>>
>>
>>I am sending config.xml,deployment descriptors, code snippet for TestSession.
>>i
>>am using weblogic6.0sp2.
>>if you need any aditional info. please let me know.
>>
>>thanks
>>ranganath
>>
>>EJB-JAR.xml
>>
>><?xml version="1.0"?>
>>
>><!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
>JavaBeans
>>1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
>>
>><ejb-jar>
>> <enterprise-beans>
>> <session>
>> <ejb-name>TestSession</ejb-name>
>> <home>com.apar.sslbridge.test.TestHome</home>
>> <remote>com.apar.sslbridge.test.TestRemote</remote>
>> <ejb-class>com.apar.sslbridge.test.TestBean</ejb-class>
>> <session-type>Stateless</session-type>
>> <transaction-type>Bean</transaction-type>
>> <resource-ref>
>> <res-ref-name>jdbc/oraclePool</res-ref-name>
>> <res-type>javax.sql.DataSource</res-type>
>> <res-auth>Container</res-auth>
>> </resource-ref>
>> </session>
>> </enterprise-beans>
>> <assembly-descriptor>
>> <container-transaction>
>> <method>
>> <ejb-name>TestSession</ejb-name>
>> <method-intf>Remote</method-intf>
>> <method-name>*</method-name>
>> </method>
>> <trans-attribute>Required</trans-attribute>
>> </container-transaction>
>> </assembly-descriptor>
>></ejb-jar>
>>
>>
>>TestSession CODE:
>>
>>
>> public void doJob1() throws RemoteException
>> {
>> Statement st = null;
>> String query=null;
>> try{
>> con=getConnection();
>> st=con.createStatement();
>> query="insert into x values("+x+++")";
>> System.out.println(query);
>> int rec=st.executeUpdate(query);
>> }catch(SQLException sqle)
>> {
>> System.out.println("SQL Exception "+sqle);
>> throw new RemoteException("RemoteException*****SQLError");
>> } catch (Exception e) {
>> System.out.println("Exception "+e);
>> throw new RemoteException("RemoteException*****GenralError");
>> }
>>}
>>
>>
>> public void doJob2()throws RemoteException
>> {
>> Connection con=null;
>> Statement st = null;
>> String query=null;
>> try{
>> con=getConnection();
>> st=con.createStatement();
>> query="insert into y values("+x+++")";
>> System.out.println(query);
>> int rec=st.executeUpdate(query);
>> }catch(SQLException sqle)
>> {
>> System.out.println("SQL Exception "+sqle);
>> throw new RemoteException("RemoteException*****SQLError");
>> } catch (Exception e) {
>> System.out.println("Exception "+e);
>> throw new RemoteException("RemoteException*****GenralError");
>>}
>>}
>>private Connection getConnection(){
>>try {
>>Connection con = StaticParams.POOL_DATASOURCE.getConnection();
>>return con;
>> } catch(Exception e) {
>> System.out.println("TestBean.getConnection() Unable to get get pool
>>connection
>>" + e);
>> }
>>}
>>
>>
>>
>>
>>"Priscilla Fung" <[email protected]> wrote:
>>>
>>>It should work if you are using TxDataSource. Could you post your
>config.xml,
>>>deployment descriptors, code snippet for TestSession?
>>>
>>>Regards,
>>>
>>>Priscilla
>>>
>>>"Ranganath" <[email protected]> wrote:
>>>>
>>>>Hi,
>>>>
>>>> I am using UserTransaction in Stateless Session bean .
>>>> Transaction is not rolling back.
>>>>
>>>>The following code is writen in stateless session bean. In UserTransaction
>>>>i am
>>>>calling Two methods of another stateless session bean.
>>>> The problem is if doJob2() method fails, doJob1() method is rolling
>>>> back. These
>>>>two methods consist of SQL statement with different Connection Object
>>>>from TXDataSource.And
>>>>session bean(TestSession) is set to CMT, attribute as "Required".
>>>>
>>>> try{
>>>> Context ictx=new InitialContext();
>>>> TestHome home=(TestHome)ictx.lookup("TestSession");
>>>> utx = sessionCtx.getUserTransaction();
>>>> utx.begin();
>>>> TestRemote remote=home.create();
>>>> remote.doJob1();
>>>> remote.doJob2();
>>>> utx.commit();
>>>> }catch(Exception e)
>>>> {
>>>> try{
>>>> utx.rollback();
>>>> }catch(Exception ex)
>>>> {
>>>> System.out.println("unable to rollback"+ex);
>>>> }
>>>> }
>>>>if any SQL Exception as occured in doJob2(), its calling method utx.rollback()
>>>>in catch block. but SQL statements executed thru. doJob1() are not
>>rolling
>>>>back.
>>>>what might be the reason?
>>>>
>>>>thanks
>>>>Ranganath
>>>
>>
>
-
We are writing a J2EE application and using Weblogic 5.1 on Unix machine. We are
considering writing some Stored Procedures or Triggers on Oracle DBMS. Hence our
Stateless Session Beans / Data Access Objects (DAOs) would be calling those stored
procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These Data
Access Objects are running under the umbrella of a Stateless Session Beans). We
are using WebLogic's Connection Pooling.
Our question is: Would we get reliable rollbacks from our stored procedures. I
mean would the Transaction Management process of the EJB container work. Remember
the SQL is written in the Database (Oracle in this case) in the form of Stored
Procedures / Triggers through PL/SQL.
Any ideas or tips would help.
I would agree with Cameron Purdy. Be very cautious to use Oracle specific
Triggers / Stored Procedures. Consider following, (apart from what he said):
1. Unreliable behaviour of the Oracle JDBC drivers, specially 8.1.6 family..
(You may visit the Oracle's web site and see the newsgroups for the JDBC drivers).
This is enough of a reason to stop right there.
However for interest sake you may consider following issues:
2. By use of Oracle specific Triggers / SPs the application will not be portable.
Vendor Lock In. Remember your choice for J2EE compliant Server (WebLogic in this
case). The whole purpose would be defeated by going for this option.
3. There are issues related to the extensibility of the application. I have
my reservations and would hold my breath on two phase commit protocol transactions
being reliable in this scenario.
Have fun...
Terry
"Cameron Purdy" <[email protected]> wrote:
>Yes, the work performed by the SPs and the triggers would be in the same
>tx.
>
>What would NOT work is if the data has been read into WebLogic and then
>it
>gets affected by a trigger or SP on the RDBMS, the data in WebLogic is
>not
>automatically re-read within that same tx so you need to be careful.
>
>Peace,
>
>--
>Cameron Purdy
>Tangosol Inc.
>Tangosol Coherence: Clustered Coherent Cache for J2EE
>Information at http://www.tangosol.com/
>
>
>"Ahmad" <[email protected]> wrote in message
>news:[email protected]...
>>
>> We are writing a J2EE application and using Weblogic 5.1 on Unix machine.
>We are
>> considering writing some Stored Procedures or Triggers on Oracle DBMS.
>Hence our
>> Stateless Session Beans / Data Access Objects (DAOs) would be calling
>those stored
>> procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These
>Data
>> Access Objects are running under the umbrella of a Stateless Session
>Beans). We
>> are using WebLogic's Connection Pooling.
>> Our question is: Would we get reliable rollbacks from our stored
>procedures. I
>> mean would the Transaction Management process of the EJB container
>work.
>Remember
>> the SQL is written in the Database (Oracle in this case) in the form
>of
>Stored
>> Procedures / Triggers through PL/SQL.
>> Any ideas or tips would help.
>
>
-
Making AQ usage transactional across session beans, using mosly JMS syntax
I need to determine what I need to have in place in order for JMS/AQ messages to be "fully transactional".
I have a J2EE server application that will send JMS/AQ messages to a queue. I have a standalone application that reads messages from the queue, does some work, and then makes calls on multiple session beans (hosted in the original J2EE server application). Actually, it would likely be multiple calls to the same session bean method.
Once the standalone application reads a message from the queue, I need to ensure that if any action performed as a result of that message fails, that all the operations performed, including the removal of the message from the queue, are rolled back.
First of all, if I use an Oracle XA-compliant datasource, if one of the session bean calls fail, I can rollback the current transaction, but will this properly roll back any work that earlier session bean calls (made on the same transaction) did, even if they were successful (at the time)? Note that I have two JVMs, one running the J2EE application, and the other a standalone application reading from the queue.
Second, on committing or rolling back the message retrieval itself, I noticed from examples in the Oracle AQ Application Developer's Guide that if I create my QueueSessions with "AQDriverManager.createAQSession()", that I can pass a Connection object, and then later "commit" or "rollback", manually, perhaps if I got an EJBException from a session bean call.
However, I am trying to write my JMS/AQ code so that it uses as little of the direct AQ api as possible, staying with the standard JMS api. As a result, I'm using the JMS version of this, which is "QueueConnection.createQueueSession()". When I do this, however, it seems as if I lose control over the transaction.Ok, I think I've answered some of this for myself, but I still have some concerns.
I see that the QueueSession object that I get back from "queueConnection.createQueueSession()" is likely going to actually be an instance of the "AQjmsSession" class, so I can cast to that, and then I can call "commit" or "rollback".
What is unclear from the javadoc description is what happens when "close()" is called on the session object. Does this do an implicit "commit()", perhaps unless "rollback()" has already been called?
I'm still a little uncertain about whether the scope of my transaction will be wide enough to protect everything that needs to be protected.
For instance, I assume that my transaction starts when my consumer (not in an application server) reads the message from the queue. At that point, my consumer does some "screen-scraping" work. When it's done, it will call a session bean on the application in the application server (separate JVM, in other words), which will create some EJB entity objects and also insert raw database rows. The session bean will then return, and then the original method which read a message from the queue will be completed.
What I need to know is what will happen if ANYTHING in that process fails, either in the external consumer, or in the session bean, or creating EJB entities? That is, will the entire transaction be rolled back, undoing the EJB entity creations AND the removal of the message from the message queue?
If this can possibly work, I'm assuming this would be utilizing an XA datasource, or a non-emulated data source (which I think means the same thing). -
Can CMT Session Bean call BMP Entity Bean in WebLogic 6.0?
Hi
Does anybody successfully use CMT Session Bean calling BMP +CMT Entity bean in
WebLogic6.0? I have the following problem.
Any idea will be appreciated.
--Winston
Let's say we have a Session bean SB, it uses container to manage the transaction.
A method of SB will call an Entity Bean EB which adopts bean-managed persistence.
Both SB and EB use CMT and all of their methods use "required" in the descriptor
file.
1. If the connection con.getAutoCommit() is true in the EB, then the transaction
within SB cannot be rolled back as the ejbCreate() has already commit into the
database.
2. On the other hand if Connecton of EB con.getAutoCommit() is false, then container
cannot successfully commit the transaction from SB's method, as EjbCreate and
EjbStore() in EB are likely using the different database connections, which causes
EbjStore() fail and the following error message will be sent to the Console:
============================================================
"<Jul 9, 2001 4:16:48 PM PDT> <Error> <EJB> <Exception during commit of transacti
on transaction=(IdHash=7738920,Name = [EJB TraderBeanImpl.buy()],Xid=105:5e6719a
ded42e332,Status=Rolled back. [Reason = weblogic.utils.NestedRuntimeException:
E
rror writing from beforeCompletion - with nested exception:
[java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEntityE
xception: ejbStore: AccountBean (4003) not updated]],numRepliesOwedMe=0,numRepli
esOwedOthers=0,seconds since begin=0,seconds left=30,SCInfo[examplesServer]=(sta
te=rolledback),properties=({weblogic.transaction.name=[EJB TraderBeanImpl.buy()]
})): java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEnt
ityException: ejbStore: AccountBean (4003) not updated
at weblogic.ejb20.internal.EJBRuntimeUtils.throwRemoteException(EJBRunti
meUtils.java:57)
at weblogic.ejb20.manager.DBManager.beforeCompletion(DBManager.java:364)
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
er.java:211)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
erSCInfo.java:511)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
rverSCInfo.java:78)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
dChain(ServerTransactionImpl.java:893)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
ServerTransactionImpl.java:1229)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:168)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:2
01)
at examples.ejb.basic.statefulSession.TraderBeanEOImpl.buy(TraderBeanEOI
mpl.java:37)
at examples.ejb.basic.statefulSession.TraderBeanEOImpl_WLSkel.invoke(Tra
derBeanEOImpl_WLSkel.java:76)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
va:373)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
va:237)
at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestH
andler.java:118)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
.java:17)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion - wit
h nested exception:
[java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEntityE
xception: ejbStore: AccountBean (4003) not updated]
at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManag
er.java:220)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(Serv
erSCInfo.java:511)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(Se
rverSCInfo.java:78)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAn
dChain(ServerTransactionImpl.java:893)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(
ServerTransactionImpl.java:1229)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:168)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:2
01)
at examples.ejb.basic.statefulSession.TraderBeanEOImpl.buy(TraderBeanEOI
mpl.java:37)
at examples.ejb.basic.statefulSession.TraderBeanEOImpl_WLSkel.invoke(Tra
derBeanEOImpl_WLSkel.java:76)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
va:373)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
va:237)
at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestH
andler.java:118)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
.java:17)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.transaction.RollbackException: Unexpected exception in beforeCompletion
: sync = weblogic.ejb20.internal.TxManager$TxListener@356eb0
Error writing from beforeCompletion - with nested exception:
[weblogic.utils.NestedRuntimeException: Error writing from beforeCompletion -
wi
th nested exception:
[java.rmi.NoSuchObjectException: Exception from ejbStore:javax.ejb.NoSuchEntityE
xception: ejbStore: AccountBean (4003) not updated]]
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(
TransactionImpl.java:1261)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTran
sactionImpl.java:218)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:2
01)
at examples.ejb.basic.statefulSession.TraderBeanEOImpl.buy(TraderBeanEOI
mpl.java:37)
at examples.ejb.basic.statefulSession.TraderBeanEOImpl_WLSkel.invoke(Tra
derBeanEOImpl_WLSkel.java:76)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
va:373)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.ja
va:237)
at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestH
andler.java:118)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest
.java:17)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>"
We did receive a 4.5.1 / 5.1 interoperability patch - but it wasn't quite 'seamless'.
We never tried to use it.
SOAP? Isn't that around 50 times slower than RMI?
Mike
"Gary Mui" <[email protected]> wrote:
We ran into this issue last fall and got some feedback from weblogic
support. They originally said that it could be done (as well as different
versions talking to one another via JMS) but it turned out that they
were
incorrect and ended up saying that it is not possible. Before 6.0 went
GA,
BEA said that there would be a interoperability patch to do this, but
I've
never seen nor heard of anything regarding it. As a workaround, we
implemented 4.5.1 / 6.0 communication via SOAP.
Mike Reiche wrote in message <3b1bcaec$[email protected]>...
I have the same question - and more. Last year we were told that wecould
not use
RMI (and ejbs) between 4.5.1 and 5.1. Which seems kinda weird becauseI've
heard
of people using WL ejbs from Tomcat. This issue has caused us to avoidusing
WL ejbs in any future development which has any chance of ever beingused
by any
app server (WL included) that is not under the direct control of thedata
center.
I've been trying to convince the Architecture team here that we canuse WL
EJBs
and we can call them from other app servers - but can't seem to getany
supporting
statement from BEA (maybe I haven't tried hard enough).
Anyway, a response from BEA would be appreciated.
- Mike
"Madhu K" <[email protected]> wrote:
Is it possible to call a (stateless session) bean deployed in weblogic
6.0
from a bean in weblogic 5.1? I have two versions of weblogic running
on two
different hosts and I have to call a bean that is running in 6.0 from
5.1.
Are there any limitations?
Appreciate any feedback/suggestions.
Thanks,
Madhu -
Transaction Management - App Module in Stateless Session Bean
Hi All,
We are using Application Module in local mode in a Stateless Session Bean. The application module gets the database connection from the datasource of the application server(Oracle 9iAS).
The problem that we are facing is as follows
- When a database update/insert is made using the Application Module and the ViewObject (and the underlying Entity Object), the changes are not being commited.
Please note that we are not using the ApplicationModule.getTransaction.commit() as it does not give us commit/rollback control from another Session Bean/UseCase. We instead are relying on the Container to manager the transaction and commit the database changes. But the container does not seem to refresh the changes to the database.
Q1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?
Any help in this matter would be greatly appreciated.
-Ankur SinhaQ1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?For stateless beans you have to call postChanges in the business method for the changes to be applied to the db. For stateful beans bc4j we do that automatically just before the transaction ends.
Take a look at the following howto
http://otn.oracle.com/products/jdev/howtos/bc4j/ejbstateless_with_bc4j.html
In 9.0.3 you'll be able to create a stateless service bean declaritively.
dhiraj Hi dhiraj,
- I looked at the example but was not able to find the ContainerManagedTxnHandlerImpl class in the BC4J jars. Can you point me to the latest version of BC4J on technet ?. I already have JDeveloper 9.0.2
- Regarding your response, what do you mean by creating stateless service bean declaritively ?
Thanks,
Ankur -
Transaction inside a stateful session bean
I've a stateful session bean that represents a shopping cart.
It has the following checkout method():
<pre>
/* em.getTransaction().begin(); */
reasons.clear();
for(CartEntry ce : entries){
// get the book reference for the cart entry
Book relbook = books.findById(ce.getBook().getId());
if( ce.getQuantity()> relbook.getQuantity() ){
reasons.add("Item not availabel in this quantity");
// TODO: need to rollback
/*em.getTransaction().rollback();*/
throw new Exception();
} else{
// update book quantities
relbook.setQuantity( relbook.getQuantity() - ce.getQuantity() );
/*em.getTransaction().commit();*/
// end of conversational state
cancel();
</pre>
This method checks for the quantity of the items with respect to the quantity in the cart entries.
How can I perform a transaction here?
I'd like to rollback it before throwing the exception. And I'd like to commit it at the end,.
If I use the entity manager to get the transaction, I get this error:
Exception Description: Cannot use an EntityTransaction while using JTA.Its sad to see someone using EJB technology and then completely throw all benefits of it out of the window. I highly advise you to look into Container Managed Transactions; learn what they help you to do and then apply it. When you know how, it will put a smile on your face as you'll see the transaction management stuff disappear before your eyes.
, from the time by which I decrement the item quantity in the database to the commit, no other transaction is decrementing the quantity of the same item as well??? Am I protected against this???Concurrency is a hard problem with no clearly defined answers to it other than "you need to design the code to guard against concurrency problems". In this specific case, the database protects against this happening by applying a row lock or a table lock while the transaction is active and you are making modifications. For more information about that, you should consult the documentation relating to your specific DBMS. -
Cannot remove stateful session bean when transaction timed out
The transaction timeout is set to 5 minutes. After several operations on the transactional
stateful session bean(implements SessionSynchronization), the transaction timed out
after 5 minutes and I got the IllegalStateException when calling another business
method. After the transaction rolled back, weblogic.ejb20.locks.LockTimedOutException
was thrown when attempting to remove the bean. It seems the lock on the bean was
not released even though the transaction had been rolled back. Does anyone know how
to remove the bean in this kind of situation?
Here is the stacktrace:
####<Jun 11, 2002 2:39:35 PM PDT> <Notice> <EJB> <app1x.zaplet.cc> <server25044server>
<ExecuteThread: '11' for queue: 'default'> <> <23168:7b09681c532dc7e3> <010015> <Error
marking transaction for rollback: java.lang.IllegalStateException: Cannot mark the
transaction for rollback. xid=23168:7b09681c532dc7e3, status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException:
Transaction timed out after 299 seconds
Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]>
java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=23168:7b09681c532dc7e3,
status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction
timed out after 299 seconds
Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]
at weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(TransactionImpl.java:1486)
at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:466)
at weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.java:255)
at weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:215)
at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:371)
at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:169)
at mypackage.MyBean_wbr3eg_EOImpl.addRecipients(MyBean_wbr3eg_EOImpl.java:450)
####<Jun 11, 2002 2:39:37 PM PDT> <Info> <EJB> <app1x.zaplet.cc> <server25044server>
<ExecuteThread: '11' for queue: 'default'> <> <> <010049> <EJB Exception in method:
remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
Group for Queue: 'default'].>
weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
Group for Queue: 'default'].
at weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:448)
at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:258)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:226)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:216)
at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:310)
at weblogic.ejb20.manager.StatefulSessionManager.remove(StatefulSessionManager.java:754)
at weblogic.ejb20.internal.StatefulEJBObject.remove(StatefulEJBObject.java:86)
at mypackage.MyBean_wbr3eg_EOImpl.remove(MyBean_wbr3eg_EOImpl.java:7308)If a stateful session throws a RuntimeException (your rollback) the container destroys the instance of the bean and all
associated state information is lost, as required by the EJB specification.
If you want to maintain client state it is generally best to use HttpSession objects (if you have a web application)
for short-lived, client-specific data and JPA entities or other database backed storage for long-lived data.
Maybe you are looking for
-
Hi All, How to implement cache seeding in OBIEE 11G.? Please help. Thanks SwathiP
-
The picture that changes ever day when you open up firefox is gone how do I get it back
How do I reset the home page to show the picture that changes ever day to a different picture when you open up firefox
-
Apple's social networking app list
I need to get Apple's social networking app list to display on a webpage. Does Apple have the list in a text format that can be used?
-
Pixelated DVD from flawless source
I recently transfered about 76 mins. of footage from my DV camera into iMovie 5.0.2. I then dropped the project into iDVD 7.0.2 and used the professional setting to master to a VIDEO_TS folder. When I burn this to DVDR a short portion (about 15 sec.)
-
Soap header authentication in as2
Is there any way to pass a SOAP header with Uname/password in Actionscript 2 webservice. I need to authenticate the SOAP request. Please help me..............