Sergio Tridente

Ranch Hand
+ Follow
since Mar 22, 2007
Sergio likes ...
Java Linux Oracle
j2ee developer, incidental linux hacker, compulsive programmer and full-time dad
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sergio Tridente

Thank you Eric. The problem was my cookies' settings in both browsers which were set not to accept "3rd party cookies". I changed that and everything works as expected.

However, IIRC, I think the default in Firefox is not to accept 3rd party cookies. Maybe, this could be mentioned however in the forums' FAQ.
10 years ago
Since the forum upgrade I am unable to edit This includes, the page for reporting bugs and submitting suggestions/enhancements.

The error message I get is "You must be logged into the Saloon to edit pages. if you are logged in, try logging out, and then logging back in." I have tried logging out and in several times but the problem persists. In case it is of any help, I have the same problem with both Firefox and Opera (cannot try IE as I am a Linux user).

Thanks in advance.
10 years ago

Originally posted by Saurabh Pillai:

An appliance to get hot water generally for bathing.

I would put the blame more on that Geiser thingy than on the computer. Two people taking showers will consume more than only one.
10 years ago
Celinio, have you tried what Paul suggested?

As he has already explained, the metadata-complete attribute indicates whether all the needed metadata is defined in the deployer descriptor. If that's the case, metadata specified in annotations is ignored. Now, the problem with your example is that you are not specifying Id in metadata (as the one deplcared in annotations is not considered).

Originally posted by Ankit Garg:
I have to get something over 90%.

Why? Seriously, why do you want to put yourself under that kind of stress? Isn't there enough stress involved in writing the exam?

Originally posted by Ankit Garg:
On the first pass I will solve the questions for their logic. I will look out for easy compile time errors. I think after the first pass I will be exhausted. So at the second pass I will look specifically for compile time errors in questions.

Choose the strategy you want, but why should you take a look at the logic first to find out later there were compiler errors? You'd be wasting your time and energy. I'd go first for compile time errors, then take a look at the logic. But that's just me. Choose whatever you feel comfortable with.

And finally. If you already know what your weak points are, then concentrate on that. Study the Collection's and IO's API. You still have one week time according to your mentioned plans. And ask yourself what it is more important: to pass an exam on to learn from the experience and become a better IT professional. When that will be clear in your mind, the rest will follow naturally, and I am sure you'll get a great score. Just don't make it your most important goal.

Ah! The best of lucks to you!

Originally posted by Akhil Maharaj:

I am trying to understand the follwoing line

� Annotations used with a setter method are ignored by the persistence provider for property-based access. �

Annotations should be applied to the getter methods when using property-based access. If you apply an annotation to a setter method, the annotation is ignored by the persistence provider.

Originally posted by Akhil Maharaj:

I understand that the foolowing code also from the same book is Property based persistence

Your code is using field-based access. Note that the @Id annotation (the only required annotation) is used on a field and not on a getter method of a property.
[ October 08, 2008: Message edited by: Sergio Tridente ]
Yes, you are right. PersistenceException is a RuntimeException and as such is a system exception from the EJB Container's point of view. However, don't forget that it is NOT an EJBException.

If your application uses session or mesage-driven beans and a call to an EntityManager method throws a PersistenceException (and if the bean rethrows that exception), the EJB Container will wrap the exception in an EJBException and rethrow it to the bean's client. Also, the bean will be discarded (as it is a system exception) and the transaction will be rolled back: in all cases(!), even if the PersistenceException was in fact a NonUniqueResultException or NoResultException. The reason behind that is that when the bean rethrows the PersistenceException, that is regarded as a system exception from the EJB Container point of view (and we know what happens with system exceptions).
Have you tried the following:

import p1.*;
import javax.ejb.EJB;
public class Main {

static private HelloUserBeanRemote hellouser;
public void hello()
hellouser.sayHello("Mr. Pradeep");
public static void main(String[] args) {
Main a=new Main();


Originally posted by Juggy Obhi:
I believe that when you regain the reference (to the new bean), Container should be intelligent enough to return you a bean with counter=10 and Tx1 and Tx2 performed in method1 and method2 respectively committed in the database. In other words a bean exactly similar to the original bean right before method3().

How would the Container achieve that? The only way I can think of would be by serializing the bean's state before a transaction begins and by restoring the serialized state in the event of a transaction rollback. Too complicated and not really practical.

I think the problem in the scenario you describe is in your application design. If the bean's conversational state is so closed related to database commits, then it should be using an extended persistence context that would expland for the life of your stateful bean.
Have you defined your data source, jdbc/ItemManager?

In order to avoid complications, when I was practising for the exam I used the "default" data source (which comes preconfigured). This is my persistence.xml:

I hope that helps.
[ September 29, 2008: Message edited by: Sergio Tridente ]
You are trying to run the client inside a Application clinet Container, right? Dependency injection on client applications work only on static variables. hellouser must be declared static.
Hi Juggy,

Let's go slowler...

1) You get a reference to stateful session bean (either thru DI or JNDI lookup)
2) You call method1(), which starts a new transaction (T1), adds one row to the database and sets the counter instance variable to 5 (here counter represents some conversational state of your stateful session bean). When the method retuns, transaction T1 is commited.
3) You call method2(), which starts a new transaction (T2), updates the row in the database and then sets counter to 10. When method2() returns transaction T2 is commited.
Up to this point, you have inserted and updated one row in the database (these changes are already commited and won't rollback) and conversational state variable counter equals 10.
4) You now call method3(), which starts its own transaction (T3), and updates again the same row in the database. But it throws now a system exception (RuntimeException). Transaction T3 is rolled back (the changes you made in the database inside this transaction are lost) and the bean instance is discarded. This implies that you cannot access its conversational state anymore, which is irremediably lost.
5) From now on, if you try to use the reference you got on step 1) you'll get a javax.ejb.NoSuchEJBException.
If you need to call method1(), method2() and/or method3(), you'll need to get a new reference to the stateful session bean: you'll get a reference to a new instance, so instance variable counter (its conversational state) will be set to 0.

I hope this makes it a little clearer.
[ September 27, 2008: Message edited by: Sergio Tridente ]
It method1, method2 and method3 share the same transaction (e.g.: extended transaction or same inherited transaction from client), then the Container rollbacks the transaction. It always discards the stateful session bean instance. Rolling back the transaction serves to avoid inconsistent state in the database and discarding the EJB instance serves to avoid inconsistent state in the bean instance.