Transaction propagation in DAO!

Hi Guys,
DAO pattern suggests that connections are obtained in DAOs itself. This means that if I am calling three DAOs from a session facade, there will be three different connections while dealing with database single transaction. Is this understanding correct?
The problem I am facing is - I am unable to make these three calls as one transaction. (Which is a result of three connections involved in the tx).
If I create a connection in session bean and then send it as parameter while calling these three DAOs, it works fine as a single tx. But I think it defeats the purpose of DAO as obtaining the connection should be the responsibility of DAO, not the session bean.
I am sure I am doing something fundamentally wrong. Can someone guide me here please?

Guy,
Thanks for the reply. I understand the bit that I must use session bean transaction as "tx_required". Can you please throw some more light on XADataSource. Are you saying that whenever there are multiple connections involved in the transaction, XADataSource should be used? If this is the case then XADataSource should be used generally all the time while dealing with DAOs because there are usually more than one DAOs in a transaction.
I was reading "J2EE design patterns" book by Deepak Alur et al and it doesn't mention XADataSource while talking about DAO design pattern, though it talks about obtaining the connection in the DAO itself. Am bit confused!
Thanks again for your input.

Similar Messages

Have a transaction propagated to two remote machines!!!(URGENT!!!)

          Can we have a transaction propagated to two ejb's in different machines if we have database interaction in both?
          I tested it out with Account beans (examples)
          deployed on two different(remote) servers both servers having the same connection pool name and the mapping to the
          same oracle database (Using the oracle thin driver as well as the Weblogic Driver). One of the beans is in a local server and one in a remote server and both are accessed in the
          same transaction context. What happens is that the 2nd bean accessed throws a Null pointer Exception
          when it tries to getConnection().
          This is the server side stack trace -----
          SQLException: java.sql.SQLException: java.lang.NullPointerException:
          Start server side stack trace:
          java.lang.NullPointerException
          at weblogic.jdbc.common.internal.ConnectionMOWrapper.<init>(ConnectionMO
          Wrapper.java:42)
          at weblogic.jdbc.common.internal.ConnectionEnv.setConnection(ConnectionE
          nv.java:142)
          at weblogic.jdbc.common.internal.DriverProxy.execute(DriverProxy.java:17
          3)
          at weblogic.t3.srvr.ClientRequest.execute(ClientContext.java:1030)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java, Compiled Code)
          End server side stack trace
          It appears that when the database call on the 2nd WL server is routed to the first WL server(the server that established the first connection for the transaction) for the database connection it is not able to find the connection( and hence the bombing). I'm going nuts over this for two days. Please help. We need to use Weblogic for our project and i need to confirm that this functionality works!!!!
          I'm attaching the stateless bean code which accesses both these beans.
          [TraderBean.java]


          Hi,
          Are you using cluster?
          Definitely you can be in one transaction if you just access one data source. that's two phase transaction.
          "kartik" <[email protected]> wrote:
          >
          >
          >
          >Can we have a transaction propagated to two ejb's in different machines if we have database interaction in both?
          >
          >I tested it out with Account beans (examples)
          > deployed on two different(remote) servers both servers having the same connection pool name and the mapping to the
          > same oracle database (Using the oracle thin driver as well as the Weblogic Driver). One of the beans is in a local server and one in a remote server and both are accessed in the
          > same transaction context. What happens is that the 2nd bean accessed throws a Null pointer Exception
          > when it tries to getConnection().
          >
          >This is the server side stack trace -----
          >SQLException: java.sql.SQLException: java.lang.NullPointerException:
          >Start server side stack trace:
          >java.lang.NullPointerException
          > at weblogic.jdbc.common.internal.ConnectionMOWrapper.<init>(ConnectionMO
          >Wrapper.java:42)
          > at weblogic.jdbc.common.internal.ConnectionEnv.setConnection(ConnectionE
          >nv.java:142)
          > at weblogic.jdbc.common.internal.DriverProxy.execute(DriverProxy.java:17
          >3)
          > at weblogic.t3.srvr.ClientRequest.execute(ClientContext.java:1030)
          > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java, Compiled Code)
          >End server side stack trace
          >-----------------
          >
          >It appears that when the database call on the 2nd WL server is routed to the first WL server(the server that established the first connection for the transaction) for the database connection it is not able to find the connection( and hence the bombing). I'm going nuts over this for two days. Please help. We need to use Weblogic for our project and i need to confirm that this functionality works!!!!
          >
          >I'm attaching the stateless bean code which accesses both these beans.
          >

Transaction propagation via plain Java classes?

          Hello,
          I have a question on transaction propagation in the following scenario:
          1. a method of EJB1 with setting "Required" is invoked.
          2. the method creates a plain Java class and invokes a method of the class
          3. the class's method invokes a method of EJB2 with setting "Required".
          Is my understanding of EJB spec correct, when I assume that the transaction created
          when the first EJB method was called will be propagated through the plain Java
          class (supposedly via association with current thread), so the second EJB will
          participate in the same transaction?
          Thank you in advance,
          Sergey


Yup, current transaction is associated with the current thread.
          Sergey <[email protected]> wrote:
          > Hello,
          > I have a question on transaction propagation in the following scenario:
          > 1. a method of EJB1 with setting "Required" is invoked.
          > 2. the method creates a plain Java class and invokes a method of the class
          > 3. the class's method invokes a method of EJB2 with setting "Required".
          > Is my understanding of EJB spec correct, when I assume that the transaction created
          > when the first EJB method was called will be propagated through the plain Java
          > class (supposedly via association with current thread), so the second EJB will
          > participate in the same transaction?
          > Thank you in advance,
          > Sergey
          Dimitri

JTA transaction propagation

          Can I just confirm that if a method in an EJB has a JTA transactional context specified
          by container-managed transaction demarcation, then the transaction context will be
          propagated to any method that it calls in any other Java class. I just wanted to
          be sure because we have all our SQL handling in separate Data Access classes whose
          methods are called from the EJBs.
          Thanks


Yes. Make sure that you are using a Transactional DataSource or the WebLogic JTS Driver to
          access the connection pool...
          Dave wrote:
          > Can I just confirm that if a method in an EJB has a JTA transactional context specified
          > by container-managed transaction demarcation, then the transaction context will be
          > propagated to any method that it calls in any other Java class. I just wanted to
          > be sure because we have all our SQL handling in separate Data Access classes whose
          > methods are called from the EJBs.
          > Thanks

Transaction propagation and integration

I am currently performing a product assesment for integration platforms (EAI/ESB).
The environment is somewhat this: there will be a J2EE architecture that envolves many types of components. In addition, there will be a integration product installed.
If a UserTransaction is started from a Session Bean and this session bean performs two types of functions. Functionalities that reside entirely inside the J2EE container and functionalitites that reside within the selected EAI/ESB product.
Is the transaction context propagated to the EAI/ESB product through some interface in a way, that would make the EAI/ESB functionalities a solid part of the transaction?
Thank you for all your help!

You will need to pick a product that supports distributed transactions. This works for example with most JMS implementations and datasources.
(see http://www.onjava.com/pub/a/onjava/2001/05/23/j2ee.html?page=3 for an explanation on the subject)
Regards,
Lonneke

Transaction propagation and ESB

I am currently performing a product assesment for integration platforms (ESB).
The environment is somewhat this: there will be a J2EE architecture that envolves many types of components. In addition, there will be a integration product installed.
A UserTransaction is started from a Session Bean and this session bean performs two types of functions. Functionalities that reside entirely inside the J2EE container and functionalitites that reside within the selected ESB product.
Is the transaction context propagated to the ESB product through some interface in a way, that would make the ESB functionalities a solid part of the transaction?
Thank you for all your help!

From the advanced architecture document I found this "slide"....
Transactions
• Global End-to-End JTA/XA Transactions
• BPEL <-> ESB <-> BPEL
• JCA <-> ESB <-> WSIF
• ESB Inherits Inbound Global Transactions
• “Async” Routing Rules ends scope of current transaction
• New ESB initiated transactions grouped by ESB System
• Transaction Exception Handling and Rollback
• Errors on existing inbound transactions rolled back to initiator
• Errors on ESB initiated transactions can be resubmitted
• End-to-end message flow terminates on first failed service
regardless of transaction state or owner
I guess "inherits inbound global transactions" means, that ESB processes/functions can be made a part of an existing transaction. If this is true, than this solves my problem :)

Transaction propagation from Oracle 8i or 9i to OC4J V2?

We have a very large Oracle 8i (8.1.6)-based application that uses PL/SQL exclusively for business logic; there are a few hundred user packages. We are considering a gradual introduction of EJB's into the mix, most likely via OC4J V2 when it is released.
Issue:
Because of the significant legacy of PL/SQL, it will be necessary to NOT ONLY be able to invoke PL/SQL and SQL from the EJB residing in the app server in a global transaction, BUT ALSO go the other direction: have a PL/SQL proc/function call out to an EJB in the app server. I theorize we can do this by setting up Java Stored Procedures that act as a facade for invoking EJB methods.
Scenario:
Oracle Forms web client invokes PL/SQL stored procedure, which invokes Java stored procedure, which looks up and invokes an EJB (EJB spec 2.0) in the app server, which invokes PL/SQL stored procedure or just plain SQL via JDBC.
Forms client -> PL/SQL SP -> Java SP -> EJB (on separate app server) -> PL/SQL or SQL.
Questions:
1) Assuming using OC4J V2 as the app server and Oracle 8.1.6 as database at both ends, will a transaction begun with the client (e.g. Forms 6i) propagate to all tiers of the call chain above? If not, why?
2) If it does work, is there anything special that must be coded in the Java stored proc, e.g. anything special usage of JTA?
3) Will it work the same in Oracle 8.1.6 and Oracle 9i?
4) Are there any problems using J2EE 1.3 API's from within Java stored procedures, given that Oracle 8i and 9i have backlevel built-in support for many of these features? In particular, I understand JServer has EJB 1.1 builtin, but what if I want to use an EJB 2.0 running in an external app server?
5) Are there any JTA incompatibilities between 8i/9i and J2EE 1.3 implementations (e.g. OC4J V2), particularly that would hamper this scenario?
6) If all is good so far, could I expect to replace OC4J with another J2EE 1.3 compliant app server (e.g. WebLogic or WebSphere) and still have same results?
7) Is it necessary to setup 2-phase commit in Oracle if the both the client-invoked and EJB-invoked databases in the above example are the same Oracle instance?

Hi Scott,
Answers appear below your questions...
Questions:
1) Assuming using OC4J V2 as the app server and Oracle 8.1.6 as database at both ends, will a transaction begun with the client (e.g. Forms 6i) propagate to all tiers of the call chain above? If not, why?Client side transactions are not supported (as far as I know), so
the answer is "no" and the reason is "not supported".
2) If it does work, is there anything special that must be coded in the Java stored proc, e.g. anything special usage of JTA?Irrelevant, since client-side transactions aren't supported.
3) Will it work the same in Oracle 8.1.6 and Oracle 9i?Yes, since neither 8i or 9i support client-side transactions.
Besides (again, as far as I know), both 8i and 9i both have the
same embedded JVM.
4) Are there any problems using J2EE 1.3 API's from within Java stored procedures, given that Oracle 8i and 9i have backlevel built-in support for many of these features? In particular, I understand JServer has EJB 1.1 builtin, but what if I want to use an EJB 2.0 running in an external app server? The database (8i and 9i) EJB container is not the same as OC4J. In
fact (as far as I know), Oracle recommends NOT using the embedded
container and using OC4J only. This means that in order for a java
stored procedure to lookup an OC4J EJB, you need to load the OC4J
JAR files into the database (via the "loadjava" tool). I haven't
tried it, but someone else posted to the forum saying he would try
it -- but I don't know how his experiment turned out. However, as
a workaround, you can use RMI in a java stored procedure. I have
successfully done this.
5) Are there any JTA incompatibilities between 8i/9i and J2EE 1.3 implementations (e.g. OC4J V2), particularly that would hamper this scenario?I don't know how to answer this question, sorry.
6) If all is good so far, could I expect to replace OC4J with another J2EE 1.3 compliant app server (e.g. WebLogic or WebSphere) and still have same results?Theoretically, J2EE compliant applications should be able to be
deployed and executed in any J2EE compliant application server.
However, another person in this forum had some difficulties in
migrating a ready built application from weblogic (I believe) to
OC4J. I think the problems were due to the application server
specific configuration differences (but I'm not sure).
7) Is it necessary to setup 2-phase commit in Oracle if the both the client-invoked and EJB-invoked databases in the above example are the same Oracle instance? I'm not sure about the status of two-phase commit support in OC4J.
Again, there is a (still unresolved, I think) thread in this forum
about some buggy commit behavious for CMP entity beans. However,
if you're asking this in the context of your scenarion (involving
client-side transactions), then it is moot, since, as I said earlier,
client side transactions are unsupported.
Hope this will help you,
Avi.

Transaction propagation between OC4J to non-OC4J J2EE container

I have a OC4J instance 10.1.3.1 containing a stateless session EJB 2.1. This bean call another session EJB in Websphere EJB container. The call goes through but the transaction is not distributed, meaning I cannot roll the transaction back from the OC4J container.
I have tried all kinds of context factories but it doesen't work. I use a XA datasource to an Oracle DB from the Websphere container.
Does anyone know how to propagate transactions from an OC4J container to another J2EE container:
Thanks
regards
A Bastell

You can specify the JNDI properties in your JSP/Java Client to lookup the EJB if it's in a different EJB container than the one provided by the JSP container.
Rob

Transaction propagation from my EJB to a SOA server

Hi,
I am developing ejb Stateless wich need to invoke bpel process. To comunicates from my EJB to SOA I'm using Worklist API an EM API.My SOA server is given me a Out Of Memory and I have seen into diagosis file that my EJB statless Trasaccitóns are trasmited to SOA Server, Is it a normal behaviour? How can avoid a Transactión trasmision?
Thaks.

Hi,
You must analyze inside the Worklist API and your SOA Server.
Which SOA Server are using ?
Which JVM configurations are you using to start the SOA server and Container Server ?
How much free memory has your machine with started JVM and while running the code section ?
If everything above going well and if OutOfMemory happen inside your application, you should try Weak and Soft Reference (Be careful with your development while coding).

Use of @Transactional in Hibernate Data Access Object

Hello
I have just started using Hibernate 3 along with Spring framework using MyEclipse and Oracle 10g.
I have started with a basic application having a single database table Customer which is represented by an annotation based POJO. Then created a simple DataAccessObject CustomerDAOImpl and an interface for that DAO CustomerDAO. CustomerDAOImpl implements the methods of CustomerDAO and extends the HibernateDaoSupport. It also contains the methods to add/modify/remove/find records from the database.
In CustomerDAOImpl i want to specify the general transactional behavior so above the class definition I have put the following:
@Transactional(propagation=Propagation.SUPPORTS, readOnly=true)
public class CustomerDAOImpl extends HibernateDaoSupport implements CustomerDAO I believe this would specify the general behaviour for all the methods in this class. If I want to change this behaviour for a specific method like in case of an add method, I will have to specify that on that method as follows:
@Transactional(propagation=Propagation.REQUIRED, readOnly=false)
public Customer insertCustomer(Customer customer) Now my question is:
1. The approach I have used to specify the transactional behaviour, is this approach correct?
2. Since CustomerDAOImpl methods are an implementation of the CustomerDAO interface, should I specify this transactional behavior also on the methods of the interface like:
@Transactional(propagation=Propagation.REQUIRED, readOnly=false)
Customer insertCustomer(Customer customer);Or is it not required to specify it on top of interface methods?
Many Thanks
Rabbia
Edited by: rabbia on Nov 5, 2009 1:07 PM

Hello,
The boolean type don't exist in ABAP.
In ABAP we used to refer to the type-pool ABAP where exists a type ABAP_BOOL (character length 1) where X = true and space = false. To refer to these values there are two constants: ABAP_TRUE and ABAP_FALSE.
To access the type-pool use the transaction SE11 select Type Group and enter ABAP.
Regards,

EJB 3.0 Core Spec (Transaction and BMT)

On Page 342 Core EJB Specs:
If the client request is associated with a transaction T1, and the instance is not associated with a transaction, the container suspends the client�s transaction association and invokes the method with an unspecified transaction context. The container resumes the client�s transaction association (T1) when the method (together with any associated interceptor methods) completes. This case can never happen for a message-driven bean or for the invocation of a web service endpoint method of a stateless session bean.
Doubt:
Message driven beans can have Transaction attribute specified as Not Supported or Required. In the case of Not Supported - the above can happen?.
Also, why is not applicable for invocation of a web service endpoint method of a stateless session bean and applicable for a stateless session bean call?
Please guide,
Shivani

Hi Shivani,
In the JMS programming model, transactions do not propagate from the message
producer to the message consumer so there is not any possibility for a transaction to propagate
into the JMS MDB's onMessage method. However, the text could actually use some qualification
since MDBs are capable of consuming other types of inbound messages through the Connector 1.5
contracts. In those cases it is possible for a transaction to propagate into the MDB.
Regarding WebServices, Java EE 5 does not require support for transaction propagation on
web service invocations. When this text was written such propagation was prohibited. That
restriction was loosened in Java EE 5 so this also needs some rewording.
--ken

Log Reader Agent: transaction log file scan and failure to construct a replicated command

I encountered the following error message related to Log Reader job generated as part of transactional replication setup on publisher. As a result of this error, none of the transactions propagated from publisher to any of its subscribers.
Error Message
2008-02-12 13:06:57.765 Status: 4, code: 22043, text: 'The Log Reader Agent is scanning the transaction log for commands to be replicated. Approximately 24500000 log records have been scanned in pass # 1, 68847 of which were marked for replication, elapsed time 66018 (ms).'.
2008-02-12 13:06:57.843 Status: 0, code: 20011, text: 'The process could not execute 'sp_replcmds' on ServerName.'.
2008-02-12 13:06:57.843 Status: 0, code: 18805, text: 'The Log Reader Agent failed to construct a replicated command from log sequence number (LSN) {00065e22:0002e3d0:0006}. Back up the publication database and contact Customer Support Services.'.
2008-02-12 13:06:57.843 Status: 0, code: 22037, text: 'The process could not execute 'sp_replcmds' on 'ServerName'.'.
Replication agent job kept trying after specified intervals and kept failing with that message.
Investigation
I could clearly see there were transactions waiting to be delilvered to subscribers from the followings:
SELECT * FROM dbo.MSrepl_transactions -- 1162
SELECT * FROM dbo.MSrepl_commands -- 821922
The following steps were taken to further investigate the problem. They further confirmed how transactions were in queue waiting to be delivered to distribution database
-- Returns the commands for transactions marked for replication
EXEC sp_replcmds
-- Returns a result set of all the transactions in the publication database transaction log that are marked for replication but have not been marked as distributed.
EXEC sp_repltrans
-- Returns the commands for transactions marked for replication in readable format
EXEC sp_replshowcmds
Resolution
Taking a backup as suggested in message wouldn't resolve the issue. None of the commands retrieved from sp_browserreplcmds with mentioned LSN in message had no syntactic problems either.
exec sp_browsereplcmds @xact_seqno_start = '0x00065e220002e3d00006'
In a desperate attempt to resolve the problem, I decided to drop all subscriptions. To my surprise Log Reader kept failing with same error again. I thought having no subscription for publications log reader agent would have no reason to scan publisher's transaction log. But obviously I was wrong. Even adding new log reader using sp_addLogreader_agent after deleting the old one would not be any help. Restart of server couldn't do much good either.
EXEC sp_addlogreader_agent
@job_login = 'LoginName',
@job_password = 'Password',
@publisher_security_mode = 1;
When nothing else worked for me, I decided to give it a try to the following procedures reserved for troubleshooting replication
--Updates the record that identifies the last distributed transaction of the server
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
-- Flushes the article cache
EXEC sp_replflush
Bingo !
Log reader agent managed to start successfully this time. I wish if I could have used both commands before I decided to drop subscriptions. It would have saved me considerable effort and time spent re-doing subscriptions.
Question
Even though I managed to resolve the error and have replication funtioning again but I think there might have been some better solution and I would appreciate if you could provide me some feedback and propose your approach to resolve the problem.

Hi Hilary,
Will the below truncate the log file marked for replication, is there any data loss, when we execute this command, can you please help me understand, the internal working of this command.
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

Transactional Behaviour of Oracle B2B 11g

Hi Gurus/Anuj,
Can you please explain Transactional Behaviour in Oracle B2B 11g?
For a Inbound Interface I have three Mediators(Mediator M1,M2 and M3)
Partner push a file at file location --> B2B Interface used in M1 ,through B2B Binding,picks the FIle and brings to SOA and--> Give it to M2 and M3.
I need to perform Error Handling in this case..
M1 M2 and M3 are Asynchronous,Synch and Synch in nature and I guess M1 will propogate it's transaction to M2 and M2 will propogate it's transaction to M3.
Routing rules are Sequential..
Note : Fault policies are applicable to parallel routing rules only. For sequential routing rules, the fault goes back to the caller and it is the responsibility of the caller to handle the fault.
Am I correct in understanding that :
B2B Adapter in M1 is the caller and M2 and M3 ,as being Synchronous,will follow M1'a transaction.
And if a Fault goes into M2 and M3,it will go back to the caller,means M1.
And in M1 we can have Fault-Handling.
Also please explain Transactional Behaviour in Oracle B2B 11g?
Is B2B is Asynchronous in nature?
Is B2B Adapter a Transactional Adapter?
What category of JCA adapter is Oracle B2B adapter?
Thanks
Vivek
Edited by: Vivek on May 19, 2011 11:41 PM
Edited by: Vivek on May 19, 2011 11:54 PM

Hi Vivek,
Also please explain Transactional Behaviour in Oracle B2B 11g?Oracle B2B depends upon the underlying transport being used for transactional behavior. As far as transaction propagation is concerned, we never had any such need in B2B communication.
Am I correct in understanding that :
B2B Adapter in M1 is the caller and M2 and M3 ,as being Synchronous,will follow M1'a transaction.
And if a Fault goes into M2 and M3,it will go back to the caller,means M1.
And in M1 we can have Fault-Handling.If you are using AQ interface of B2B adapter with XA Data Source then that adapter can participate in an XA global transaction that can span multiple resources. In this transaction, the application server acts as the coordinating transaction manager with multiple databases (or other resources such as JMS), each of which is involved in a single transaction.
If you are using JMS interface of B2B adapter with XA Connection factor then that adapter can also participate in an XA global transaction that can span multiple resources.
If you are using Default (Fabric) interface of B2B adapter then it does not participate in global transaction, rather it starts it's own local transaction and executes in that. So it will totally depend upon the interface you are using with B2B adapter that it will start and propagate a global transaction or will not participate in a global transaction. Moreover, if B2B adapter is starting a transaction and propagating it to a async service then that sync service will start a new local transaction and further sync services may execute in that transaction. As soon as the control comes back to B2B adapter, it will commit the transaction.
Is B2B is Asynchronous in nature?B2B can be used for both sync and async calls (between partners). B2B is async when communicating with middleware.
Is B2B Adapter a Transactional Adapter?Explained above
What category of JCA adapter is Oracle B2B adapter?No special category. It is a specific adapter for Oracle SOA SCA composites to facilitate them in communication with Oracle B2B. You may or may not use this adapter in SOA SCA composites.
Regards,
Anuj

When is it necessary to declare a transaction?

I am struggling to understand when it is necessary to declare my own transaction to ensure the data is properly updated.
For example, in the following code, which is part of a java bean in the EJB project, KeyFacade is a stateless session bean tied to the entity "Key". it is a standard EJB created with the netBeans 5.5 wizard. I have changed no defaults. Do I need to declare a transaction, commit the transaction and close it when I use the "KeyFacade.edit(key);" in order to ensure the database is updated? Or is it automatically done because the .edit() method uses the entityManager and the persistence is container managed? Would it make a difference if this bean was part of a WAR project?
    public BigInteger getNextKey(String tableName){
        KeyFacadeLocal KeyFacade = this.lookupKeyFacade();
        Key key = KeyFacade.findByTablename(tableName);
        long nextKey = key.getKeyvalue();
        BigInteger BINextKey =BigInteger.valueOf((int)nextKey);
        // now update the table by incrementing the key value by 1
        long incrementKey = nextKey + 1;
        key.setKeyvalue(incrementKey);
        KeyFacade.edit(key);
        return BINextKey;
    }

It depends where the method is defined. If it's defined as a business method of an EJB 3.0
Session Bean, then the default is container-managed transactions with a transaction attribute
of Required. That means if there is an existing transaction that is propagated into the business
method invocation , the work performed within the method occurs within the incoming transaction.
If there is no transaction propagated into the business method, the EJB container will automatically
start a new one and commit it after the business method completes. This container-managed
transaction demarcation behavior has nothing to do with what code is in the business method.
You can change the transaction behavior of the EJB by using the @TransactionManagement
and @TransactionAttribute annotations at either the class or bean level, as well as within ejb-jar.xml.
The web tier doesn't have any notion of container-managed transactions. To start a global
transaction from code running in the web tier, you would need to acquire the UserTransaction
object and explicitly start and commit the transaction.
--ken

Override EJB 3 transaction interceptor in OC4J 10.1.3 possible?

Hi
I'm using OC4J 10.1.3 with EJB 3 container managed transactions. I need to override the default transaction interceptor to add some additionnal logic that needs to be aware that a transaction will be commited, and I don't see any other way to do this since normal interceptors are not aware that a transaction is about to be commited when the method exits. Is there a way to do that?
TIA
Eric

Anybody? Since I'm using Bean Managed Transactions, should the transaction context be propagated through each call? When I do the same kind of test with Container Managed Transactions I can see that the transaction propagation is working... I thought it is supposed to work in both cases, the only difference being that with BMT the bean itself is managing the transaction...
Please, any help would be greatly appreciated...
Eric

Transaction propagation in DAO!

Similar Messages

Maybe you are looking for