Satya P

Greenhorn
+ Follow
since Jul 01, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Satya P

I have two Queries related to Propogation of Extended Persistence Context:

1) Are Extended Persistence contexts propagated with the transaction?

2) If Answer to 1) is YES,
If Component A is using Extended Persistence Context and Component B is using Transaction Persistence Context, Is the Persistence Context from Component A propogated to Component B (Assuming that the transaction is propogated from A to B).

Thanks in advance,
Satya
As defined in chapter 5.5 of persistence specs

--------
A container-managed entity manager must be a JTA entity manager. JTA entity managers are only specified
for use in Java EE containers

Both JTA entity managers and resource-local entity managers are required to be supported in Java EE
web containers and EJB containers.Within an EJB environment, a JTA entity manager is typically used.
--------

My Query
-------
In Java EE , assume that the EntityMangerFactory is configured for �Resource Local Entity Manager�. Its known that Container Managed EM does not support use of Resource local Transactions. Does this mean that Container Managed EM cannot be created in such cases?
-------

Thanks in advance
Satya
The Persistence specs (chapter 2.1.6) say as follows:

------------------------------------
�If a persistent field or property other than a relationship property is not annotated with one of the mapping Annotations (or equivalent mapping information is not specified in the XML descriptor), the following default mapping rules are applied in order

If the type is a class that is annotated with the Embeddable annotation, it is mapped in the same way as if the field or property were annotated with the Embedded annotation.
----------------------------------------
Does this imply that @Embedded annotation is not mandatory.

Thanks in advance
Satya
In "Orielly EJB 3.0 book" page 399, para 1 it is said as follows:
---------
In session beans, when a system exception occurs and the instance is discarded, a RuntimeException is always thrown whether the client is a remote or a local invocation. If the client started the transaction, which was then propagated to the EJB, a system exception (thrown by the enterprise bean method) will be caught by the container and rethrown as a javax.ejb.EJBTransactionRolledbackException . EJBTransactionRolledbackException is a subtype of RuntimeException and gives a more explicit indication to the client that a rollback occurred. If the client did not propagate a transaction to the EJB, the system exception will be caught and rethrown as an EJBException.
---------

Whereas in Table 16-1 , page 402, a cntradicting statement is made
-------------
Remote client recieve the remote exception or EJB exception.
---------------

Which is correct?
Is Remote Exception thrown or EJB exception to a Reote client?
Assume a Stateless Session bean method mA() is having transaction attribute as �RequiresNew�. A Client has called this method.

@TransactionAttribute(REQUIRES_NEW)
public void mA() throws myApplicationException
{
//update some row in database
// perform some business logic
throw myApplicationException;
}

In mA(), Container starts a new Transaction. Within that transaction, database update is done and then business logic is executed. While performing businesslogic assume that the method encountered some error and the method planned to throw the ApplicationException.
In such cases the Container does not rollback the transaction. Does it mean that the updated row is Commited to the DB at the end of the method? Is a commit performed by the container at the end of the method?

Regards,
Satya
It is said as follows in Enthuware mock test description for a query:
------------------------
Message-driven bean�s message listener method must not throw the java.rmi.RemoteException. It can throw any other exception. If it throws an application exception, the transaction (if any) is rolled back, the exception is rethrown to the resource adapter, and the bean is NOT discarded. If it throws a system exception, the exception is logged, the transaction (if any) is rolledback, and the bean is discarded.
------------------------

Q) Why should the transaction be rolled back when application exception is thrown?
My understanding is that, By default the Transaction is not rolled back when an application exception is thrown.
Hi Sanjeev,
Thanks for the reply.

As you said container might create the home object.

Now my question is what is stored in the JNDI under the name
"java:comp/env/ejb/tax".

When I perform a lookup from a 3.0 EJB to this EJB (which is also 3.0 EJB), I get the business object directly when I perform the lookup.

initCtx.lookup("java:comp/env/ejb/tax").


and when I perform the lookup from a 2.0 EJB this 3.0 EJB using the same string, I get a home object.

TaxHome taxHome = (TaxHome) PortableRemoteObject.narrow(initCtx.lookup("java:comp/env/ejb/tax"), TaxHome.class);

I am not able to understand how is this possible? Does the container take care internally all such issues? But how?
Hi,

In ENTHUWARE mock tests, explanation about a question is given as follows:

�A 2.0/2.1 bean can access a 3,0 bean as follows

Context initCtx = new InitialContext();
TaxHome taxHome = (TaxHome) PortableRemoteObject.narrow(initCtx.lookup("java:comp/env/ejb/tax"), TaxHome.class);
Tax tax = (Tax) taxHome.create();

Notice that the above client code uses the standard EJB 2.x client programming model. It does not need to know that the target bean is implemented with EJB 3.0.


Question:
---------

My understanding is that in a 3.0 EJB's business object is retreivd when we look up in JNDI.
initCtx.lookup("java:comp/env/ejb/tax").
How is the above code getting te HOME object?
3.0 EJB does not have a home, then how will the above code work?