Mihai Alexe

Indeed, most application servers allow you to influence the loading strategy for entity beans that participate in relationships (via their local business interfaces). You can have lazy-loading (my guess this is a natural default, since it usually provides optimal performance when dealing with multiple relationships), and eager-loading . With eager-loading, use it as "full" (i.e. when a bean gets loaded, load all beans that participate in a relationship with the first bean, even indirectly) with caution, since it can easily generate a whole bunch of ejbLoad() calls and unnecessary bean instances (especially when we�re dealing with many-to-many or many-to-one relationships). Of course, the lazy-loading tradeoff is more computation during bean access. It is up to you to dig in the AS documentation and see what can and what can not be done and decide your strategy. Just remember that loading strategies and a number of other optimizations are beyond (i.e. not specified) in the ejb specification. That leaves room for the AS vendors to optimize and make us AS users happier (at least in theory)

Hm,... it would appear that they posted an explanation - but not too clear - at least for me

In this case, the sending of the message is a part of MyBean's transaction. Therefore, if it rollsback the transaction, the message will not be sent.
The message will not be redelivered because it was never sent!
The database changes will not be committed because the transaction was rolled back.

Any comments on this?

Here's a sample question from a JDiscuss mock exam:

Question No: 28 (Question ID: 1940) Exceptions : Real Brainer

Consider the following code occuring in a MyBean code. It updates the database and sends a message to a queue named Q1. The message driven bean (not same as MyBean) associated with the queue requires a transaction and updates the database upon receiving a message.
Assuming that all the variables are properly defined and used, what will happen if the MDB associated with the queue Q1 rolls back the transaction but does not throw any exception?

11. public void myBeanMethod() 12. { ... 21. UserTransaction ut = ejbContext.getUserTransaction(); 22. ut.begin(); 23. queueSender.send(message); //sends a message to a queue Q1. 24. stmt.executeUpdate(query1); 25. ut.rollback(); ... 30. }

Select 1 correct option.

Changes made by the bean code at line 24 will be committed.

Line 25 will throw an Exception

The message will be sent to the queue.

The message will be sent to the queue but the changes made to the database by the MDB will not be committed.

The container will resend the message to the queue.

Neither the message is sent nor any database changes get committed.

The mock exam marks the last option as correct, while I assumed it was the 1st. Unfortunately, no other explanations are given. So please clear this up for me...it's probably somtehing with the message send() and the MDB rolling back its tx that causes the client transaction to roll back, but I'm not clear what and why - my guess is that the client code and the MDB's onMessage() run in separate transactions since the MDB requires a TX and the client's TX cannot be propagated to it [the client never "sees" the bean].

Thanks a bunch!
[ September 09, 2005: Message edited by: Mihai Alexe ]

Hi all!

One question: while browsing the EJB 2 API specification, I noticed that there are several methods that have the declared return type as either EJBHome or EJBObject. A couple of examples:

public EJBHome getEJBHome()

from HomeHandle

public EJBObject getEJBObject()

from SessionContext.

My question is: do I have to narrow the result of any of these methods or a simple Java cast to my Component or Home interface will suffice?

Thanks!

[ September 04, 2005: Message edited by: Mihai Alexe ]
[ September 04, 2005: Message edited by: Mihai Alexe ]

A) aHandle must be Serializable.
B) Advice must extend EJBHome
C) The object referenced by aHandle is from a class implemented
the container
D) The Bean Provider implemented the aHome.create() method.
E) getHandle() declares a RemoteException
F) Handle extends java.rmi.Remote
G) The object referenced by 'a' IS-A java.rmi.Remote

A - yes; Handles implement the javax.ejb.Handle interface and that interface extends Serializable [see EJB API specification]

B. no - Advice is an EJB Object reference, therefore it must implement EJBObject, not EJBHome.

D.- no; the bean provider provides only the component interface, i.e. only the create method declaration. The container is responsible for the actual implementation. The create() method here would be implemented in the Session EJBHome class implemented by the container [see spec page 100]

E. yes; since EJBObject implements java.rmi.Remote, every method declaration must contain in RemoteException in the throws clause. In this case: public Handle getHandle()
throws java.rmi.RemoteException

F - no; see API documentation

G. yes; every EJB Object is-a Remote object [i.e. indirectly implements the java.rmi.Remote interface]

C - yes; the deployment tools are responsible for implementing the handle classes for the session bean's remote home and component interfaces [see EJB2.0 spec page 101]
[ August 27, 2005: Message edited by: Mihai Alexe ]

Hi,

I posed the same question a few days ago: EJB 3.0 is too far away to consider a wait, and EJB 2.1 added too few things to be worth an upgrade in the Sun exam. So we'll have SCBCD 1.3 until EJB 3.0 settles in and then a major upgrade to SCBCD 1.5 or 5.0 or what have you


Mihai.

Any news about a possible update of the SCBCD exam to J2EE 1.4? It's been quite long since Sun released this spec and it has established itself on the market pretty well by now, therefore I'm expecting Sun to update its certification exam. Does any of you have more info about whether Sun is going to make this move or not in the next few months? The thing is, I've already started my preparation for SCBCD for j2ee1.3 and I'd like to find out whether it's going to be updated any time soon - if it is, then perhaps I'll concentrate on the new exam version. I see SCWCD is already at its j2ee1.4 version and it would be natural to shift SCBCD as well...

What rumours are there on this issue?

Hey guys,

I passed SCJP a couple of weeks ago and I had to give the certificate to the firm where I'm currently working as a Java programmer. My question is, is there any way to obtain another certificate from Sun? Perhaps I'll need it for a resume or CV some day... so please advise if you can.


Mihai

Try entering a sequence of values that cause an infinite loop to occur and then step with any IDE debugger to see what fails. This should reveal the problem.
[ May 23, 2005: Message edited by: Mihai Alexe ]

Perhaps you could get in touch with Prometric via e-mail... write them and ask for your candidate number [give them all the necessary personal data of course]. You can find an email on the Prometric official site.


Hope this helps.

Mihai.

Hey guys!

Just passed SCJP this morning with 95% [58/61]... well, a nice start Definitely going for SCJD now....

All the best to you and good luck for all those who are planning to take this exam!


Mihai

Hi all,

I've come upon a question in the Whizlabs SCJP simulator and I need some clarifications. Look at the following code snippet:
class CatchTest { void catchTest() { System.out.println("before try"); try { } catch (Throwable t) { System.out.println("Inside catch"); } System.out.println("after try"); } }

Why doesn't the compiler reject this code? The code inside the catch block seems unreachable to me... I mean there's no exception thrown so how could the System.out.println statement be reached? Note that I've replaced Throwable by some other exception type [now checked] - IOException and now the compiler correctly points out the problem. Is the exception type inside the catch block that makes the compiler accept this code?

Thanks for any input.

The problem with your code is that the Anonymous default constructor gets called somewhat "recursively". When you are calling the Anonymous constructor inside main() (i.e. new Anonymous()), the component objects get initialized first. That is, the constructor gets called again, because the an objects [of type Anonymous as well] needs to be assigned its value before the constructor finishes. There you go - an infinite constructor call chain - eventually ending in a StackOverflowException. I used the IBM JDK as well, and it refused to load my class - perhaps this compiler is a little "smarter" than the SUN javac

I think what you're seeing here is the ouput from the System.out.println(tmp) inside countDown(), not from the finalizer's println(). Moreover, the finalizer you wrote is for the gc class and not for the string objects constructed inside countDown()... so it misses the point . Anyway, remember that there is no guarantee the finalizer will be run - and is even less likely that all objects will be finalized (or GC'd) in the order they were created.

Don't forget to call super.finalize() inside your class's finalizer, or use a finalizer guard instead (see Josh Bloch's book for details).

Well, how did you assume the 11th object remains on the heap? I believe that all objects or even none of the 10 that are eligible for GC can still be on the heap when line X gets executed. It depends whether the garbage collector is run or not and whether the respective objects' storage is reclaimed... I hardly see the point here... I'm asking why does the 11th object remain accessible? Where is it referenced from?


As far as System.out is concerned, it's an object that handles output to the console, so it shouldn't keep a track [i.e. reference] to all objects sent to its println / print methods - this seems reasonable, as doing otherwise would keep objects from being GC'd until System.out itself becomes eligible for garbage collection [and I'm not sure this happens at all during the program's execution...]
[ April 17, 2005: Message edited by: Mihai Alexe ]