cyril vidal

Greenhorn
+ Follow
since Nov 02, 2004
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 cyril vidal

Studied for three weeks with Head First EJB book, EJB 2.0 spec, Mikalai Zaikin's SCBCD Guide , http://www.ejbcertificate.com/ exam simulator, and of course Javarach's saloon.

Thanks to all for your great help,
Regards,
Cyril.
19 years ago
Hi,

Just remarked something wrong in HFE about an DD extract p.389, concerning MDB.
The XML spec says you have to follow the order given from a DTD in your XML document.

So,


is not correct according to the ejb-jar.xml's DTD



the DTD snippet should also look like this:



Regards,
Cyril.
Hi,

in spec p.352, it's said that for an entity bean, the transaction attributes must be specified, for the methods defined in the component interface and all the direct and indirect superinterfaces of the component interface, exluding some methods, and including by example remove() from EJBObject.

My question is the following: how we do to declare it in the DD, under the name of ejbRemove()?
And what about the EJBHome's remove(Object PK) and remove(Handle handle) ? We declare them also under the name of ejbRemove() in the DD?



Thanks for your response,
Regards,
Cyril.
Hi,

HFE p.208 from ready state to does not exist state, we can read: ejbRemove() or timeout.
Of course, we should read remove() or timeout instead, because both of them imply ejbRemove() to be called, as mentionned in the spec p.77 and p.79.
Error not mentionned in o'reilly's errata pages..

Regards,
Cyril.
Hi,

HFE p.576: supposed error not seen in o'reilly errata pages.
The assembly-descriptor element doesn't tell at all the ways in which beans refer to one another.
the ejb-ref or ejb-local-ref elements stand in entreprise-beans element...

Regards,
Cyril
Hi,

HFE p.499 on unspecified transaction context.
All the methods that are said to run in unspecified context:
1�) any CMT method marked NotSupported, Supports or Never
2�) CMT session bean methods ejbCreate(), ejbRemove(), ejbActivate() and ejbPassivate.
3�) CMT message driven bean methods ejbCreate() and ejbremove().

First remark:
on 2�) why the only mention of CMT. According to the spec, BMT session bean methods ejbCreate(), ejbRemove(), ejbActivate() and ejbPassivate also run in a unsppecifed context.
What about the afterCompletion method in case of CMT stateful bean? It also runs in a unspecifed transaction context.
Second remark:
What about ejbActivate() and ejbPassivate() methods of entity beans that also run in a unspecified context according to spec p.180?

Regards,
Cyril.
[ November 20, 2004: Message edited by: cyril vidal ]
hi,

I supose that *transaction demarcation API* is javax.transaction.UserTransaction's methods.



I don't suppose so...
See [27] p.334 of the spec:

The terms resource-manager udsed in this chapter refer to the ressources declared in the deployment descriptor using the resource-ref element. This includes not only databases resources, but also JMS connections...these resources are considered to be all managed by the container



and p.340:

While an instance is in a transaction, the instance must not attempt to use the resource-manager specific transaction demarcation API i.e must not commit or rollback method on the java.sql.Connection interface or on the javax.jms.Session interface



in case of BMT cf spec p.340 �17.3.3, it's probably because nested transactions are not allowed.
in case of CMT, cf spec p.348 �17.3.4, its's because

you shouldn't interfere with the Container's demarcation of transaction boundaries



Sometimes, it's worth reading the spec;-)

Regards,
Cyril.
[ November 18, 2004: Message edited by: cyril vidal ]
Hi,

I read in HFE p.460 as well as in spec 15.4.8 p.317 that if the message driven bean uses container managed transaction demarcation, message acknowledgment is handled automatically as a part of the transaction commit. (that is, if I unserstand well, if transaction commits, the receipt will is acknowledged by the container and if the transaction fails, no receipt and the JMS provider will resend the message).

But, as far as I know, it's allowed to specify two attributes for a transaction in CMT: Required and NotSupported.
For Required, what the spec explains is OK, because there's a valid transaction context.
But if NotSupported is specified, there's no valid transaction context present and I don't understand how in this case, acknowledgment should be tied to the transaction.
In this case, should'nt we use the tag <acknowledge-mode> too, as we do for BMT?

Thanks for youe responses,
Regards,
Cyril.
[ November 15, 2004: Message edited by: cyril vidal ]
Hi,

IN HFE, it's said that in case of system exceptions , the container will always rollback the transaction, and throw either a RemoteExceptionn (remote view) or EJBException (local view). cf p.534

However, in the spec, there's a distinction to be made between rollback the transaction and mark the transaction for rollback.

This distinctin may concern first CMT vs BMT demarcation.
By example, for Message Driven Bean table 17 spec p.377 we can see that the container's action concsists in rollback the container-started transaction whereas the container's action consists in mark for rollback the transaction that has been started in case of BMT.

This distinction between rollback and only mark for rollback may have an impact also in the kind of exceptions thrown by the container.
Indeed, in the case of session or entity bean's business methods running in the context of the caller's transaction (table 15 p.375 spec) the container only marks the transaction for rollback and also throw javax.transaction.TransactionRolledbackException to Remote Clients and throws javax.ejb.TransactionRolledbackLocalException to Local Clients.
But in the case of session or entity bean's business methods running in the context of a transactio that the Container started immediately before dispatching the business method (this may happen with Required and RequiresNew attributes), the Container rollbacks the container-started transaction (table 15 p.375 spec) and throw RemoteException to remote clients and EJBException to local clients.

That's just for more complete information...
Regards,
Cyril.
[ November 12, 2004: Message edited by: cyril vidal ]
Hi,

In HFE p.550, it is said hat you always can throw a RemoveException from your ejbRemove() method in case of stateless session bean (even if the client will never see it).

To my sense, because the ejbRemove() method from SessionBean interface doesn't declare the javax.ejb.RemoveException (application exception), you are NEVER allowed to throw a RemoveException in a SessionBean's ejbRemove() method, either a stateless or stateful one.

So to my sense, You only may prevent removal from entity beans because the ejbRemove() method of EntityBean precisely declares javax.ejb.RemoveException...

Am I correct here?

Thanks for your responses,
Cyril.
Hi,

In HFE, p.420, as bullet point, we can read the following:

a SELECT can return either an <abstract-schema-type> (which really means the bean's local component interface type

.

AFAIK, SELECT method may return a EJBLocalObject (or collection of) or an EJBObjet (or collection of).

I didn't see the errata in the oreilly site.

By the way, HFE is an excellent book!!!

Regards,
Cyril.
Hi,

in spec EJB2.0 �10.5.3, p.176, it's told us that

The container synchronizes the instance's state before it invokes the ejbRemove method

, so if not done, it must call the ejbLoad method.
I've read the chapter dedicated to entity bean's synchronization in HFE, but didn't see anything about this subject. Did I misread?
In the same order of idea, I've noted that no page was existing, indicating us what it's allowed to do during remove, i.e.
- bean things you can do during entity construction p.327
- bean things you can do during entity creation p.338
- bean things tou can do during activation and loading p.354
- bean things you can do during passivation and storing p.355

but what about things we can do during entity's remove??

Regards,
Cyril.
hi,

my question is about passivation for stateful session beans.
Imagine you've got a reference to a variable that is not Serialisable, not a reference to component or home interface, not a reference to SessionContext, JNDI context, UserTransaction, or Resource Manager Factory.
The spec says you have to null out its value so that the passivation runs well. (and so reset the value after passivation in ejbActivate()).

What's the difference with declaring this variable simply as transient? You won't need to null out in ejbPassivate() but will still have to reset in ejbActivate() method.

Regards,
Cyril.
Hi,

Spec of EJB2.0, p.60, �6.4, we can read that

The local home interface allows a local client to do the following:
- create a new session object
- remove a session object



I think the second option is precisely NOT ALLOWED, as remove(Handle h) and remove(Object PK) can't be used by a local client.
I would say that the only way to remove a local session bean is by calling remove() method of EJBLocalObject.

Am I right and is this a 'mistake' in the spec?

Thanks for your responses,
Regards,
Cyril.