Victor Larr

Greenhorn
+ Follow
since Mar 29, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Victor Larr

Just got this error again: An unexpected error has occurred while processing your request. We apologize for the inconvenience, please try again later. Please note: your method of payment has not been charged.
I still can not register for a test. I enter voucher number, click submit and it gives me "timeout expired" or "unexpected error". The site works except registration for the test.
I am trying to register for SCWCD for 2 days now but on Prometric site it either times out when entering voucher number or it said that page not found. And they don't even have a link to who to complain.
UserTransaction for MDB has nothing to do with the user who sent message. UserTransaction is a reference to Transaction Manager. On ejbCreate() bean stores a reference to Transaction Manager and then later multiple times uses it to begin and commit transaction in onMessage() method. It is more efficient then obtaining UserTransaction every time when container invokes bean onMessage() method.
Rick,
I posted this reply to your other post

You have to define 2 interfaces A and B, B extends A and have the same methods but without RemoteException. Parent interface A will declare RemoteException and your remote interface can extend it. Your bean will implement B which does not throw RemoteException. Child can specialize or not declare exceptions when overwriting operations from parent.
You have to define 2 interfaces A and B, B extends A and have the same methods but without RemoteException. Parent interface A will declare RemoteException and your remote interface can extend it. Your bean will implement B which does not throw RemoteException. Child can specialize or not declare exceptions when overwriting operations from parent.
20 years ago
You have to define 2 interfaces A and B, B extends A and have the same methods but without RemoteException. Parent interface A will declare RemoteException and your remote interface can extend it. Your bean will implement B which does not throw RemoteException. Child can specialize or not declare exceptions when overwriting operations from parent.
Stateless session should have only one no argument create() method
If client x calls method1() and method2() of SFSB y in a transaction then container will call afterBegin(),method1(),method2(),beforeCompletion(),afterCompletion(boolean), assuming method1() and method2() have transaction attribute set to "Required". What kind of code Bean Provider would put in afterBegin(),beforeCompletion(),afterCompletion(boolean)? Bean Provider can update bean state with latest data from a database in afterBegin(), modify it in method1() and method2(), write it back into database just before transaction completes in beforeCompletion(). In afterCompletion(false) Bean Provider can undo the changes to bean state because transaction was rollbacked. In this scenario it does not make sense to access database in afterCompletion. I think writers of the EJB specs had this scenario in their mind when they decided not to let programmers access database and other ejb in afterCompletion. Someone can probably come with a reason that they need to access the database in afterCompletion() but the code can be refactored and made cleaner without doing so.
Look at the TransferObject pattern: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
Using this pattern only make sense for remote EJB. This pattern
"may Introduce Stale Transfer Objects
Adopting the Updatable Transfer Objects Strategy allows the client to perform modifications on the local copy of the Transfer Object. Once the modifications are completed, the client can invoke the entity's setData() method and pass the modified Transfer Object to the entity. The entity receives the modifications and merges the new (modified) values with its attributes. However, there may be a problem with stale Transfer Objects. The entity updates its values, but it is unaware of other clients that may have previously requested the same Transfer Object. These clients may be holding in their local cache Transfer Object instances that no longer reflect the current copy of the entity's data. Because the entity is not aware of these clients, it is not possible to propagate the update to the stale Transfer Objects held by other clients." There is no such danger with local EJB. So the code is affected if client is local or remote.
But you have to be more careful with local EJBs. If client get an object from an EJB and modifies a variable inside that object that variable will also be changed on EJB side. With remote EJB you don't have to worry about that. So your client code might be different depending if it is a local or remote client.
Yes you can access local EJB only if web container and ejb container runs inside the same JVM. For ejb lookup you put the same code in jsp as in a regular java class.
<%
Context context = new InitialContext();
MyEJBHome home = (MyEJBHome)context.lookup("myEJB");
MyEJB ejb = home.create();
%>
It is good for testing. But in a real development this code should be moved to a helper class.
In WebSphere you can even access local ejb directly in jsp page
From Sun site
RollbackException - Thrown to indicate that the transaction has been rolled back rather than committed.
Methods in javax.transaction that throw RollbackException
void UserTransaction.commit()
Complete the transaction associated with the current thread.
void Transaction.commit()
Complete the transaction represented by this Transaction object.
boolean Transaction.enlistResource(XAResource xaRes)
Enlist the resource specified with the transaction associated with the target Transaction object.
void Transaction.registerSynchronization(Synchronization sync)
Register a synchronization object for the transaction currently associated with the target object.
void TransactionManager.commit()
Complete the transaction associated with the current thread.