Tomaszz Lewandowski

Ranch Hand
+ Follow
since Sep 07, 2007
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 Tomaszz Lewandowski

Well, I had basic knowledge of EJBs, so I didn't used books, only specs (I read them twice and used many times to find answers). I also read many posts from this forum (even the old ones) and I think it is very helpful. Personally I think that SCBCD was the easiest exam (as compared to SCJP and SCWCD).
Yes, the table for table generator has as many rows as the numer of entities that use it.
I think that specification is self-contradicting in this case, because in the deployment descriptor schema there is a "method" element, but in chapter 12, the specification gives bad example:


1. How do you specify message-destination-link in annotations?
2. When you use DD to assign method-permissions and container-transactions, you can set different values for methods with the same signature from Local and Remote interfeces (method-intf subelement). How can you achive this with annotations?
As far as relationships are concerned, @PrimaryKeyJoinColumn can only be applied to @OneToOne relationship, as it "joins" two entities by their primary keys. That's why it wouldn't make sence for ManyToXXX relationships (because primary keys are "unique").
(DataSource) ctx.lookup("java:comp:env/jdbc/BarDB");
is incorrect for 2 reasons:
i) SessionContext lookup always takes name relative to java:comp/env
ii) there is a typo -> "java:comp:env" should be "java:comp/env"

@Resource(name=?jdbc/BarDB?, type=javax.sql.DataSource)
is incorrect, it won't compile. Question marks should be double quotes.

Message acknowledge by container is part of committing container managed transaction. In this case the bean marks transaction for rollback, so transaction is not committed, so message is not acknowledged, so JMS server will resend the message.

Option d is wrong, because table generator has attribute allocationSize with default value od 50, so approximately, the table will be accessed every fifty created entities.

In option D the Carot has reference to Carot, so the relationship would by one-to-one carrot with carrot, no celery.
You MUST annotatate getter accesor only.

From core spec (p.482):

The timeout
callback method invocation for a timer that is created for a stateless session bean or a message-driven
bean may be called on any bean instance in the pooled state.

So it is the container choice to use existing instance or create new one (as in your case).

In my opinion specs are clear in this matter. Core spec says (p.74):

The following steps describe the life cycle of a stateful session bean instance:
- A session bean instance's life starts when a client obtains a reference to a stateful session bean instance through dependency injection or JNDI lookup, or when the client invokes a create<METHOD> method on the session bean's home interface. This causes the container to invoke newInstance on the session bean class to create a new session bean instance.


It will be a List of Object[]. First element will be Catalogue instance, second element - Product instance, third element - Article instance.

I don't agree with this, because of the sentence:

"If a lifecycle callback method for the same lifecycle event is also specified on the entity class and/or one
or more of its entity or mapped superclasses, the callback methods on the entity class and/or superclasses
are invoked after the other lifecycle callback methods, most general superclass first."

I think that this sentence describes exactly above situation and it assumes that the same lifecycle event could be specified several times in a hierarchy.

Am I wrong?

<post-construct> and <pre-destroy> elements are in jndiEnvironmentRefsGroup in interceptorType, so the spec is correct, you can use these as subelements of element "interceptor" and "session".
I also disagree with the statement:

... in BMT your message is deleted from the queue and can't be recovered. ...

Core spec, section 5.4.17 says:

If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message

so I think that in this case the message will not be deleted from queue.

In paragraph 4.9 of persistence spec. it is said that:

When the ORDER BY clause is used in a query, each element of the SELECT clause of the query must be one of the following:
1. an identification variable x, optionally denoted as OBJECT(x)
2. a single_valued_association_path_expression
3. a state_field_path_expression
In the first two cases, each orderby_item must be an orderable state-field of the entity abstract schema type value returned by the SELECT clause. In the third case,the orderby_item must evaluate to the same state-field of the same entity abstract schema type as the state_field_path_expression in the SELECT clause.

In "Pro EJB 3 Java Persistence API" (chapter 7) there is an example of, in my opinion, incorrect query:

FROM Employee e JOIN e.department d

because, isn't listed in select clause.

But this query works perfect on Toplink Essentials. Am I misunderstanding the spec or is it a bug/feature of Toplink Essentials?