Severin Stoeckli

the ClassLoader's getResourceAsStream searchs your resource in the classpath, according to the rules of the classLoader.

the Servlet's getResourceAsStream expects a URL to the resource and can access a .war file, but not something in a .jar -file inside the .war file.

/Severin

A MDB can never be called by a client. The only thing you can do in your MDB is to send a Message to the client through the message service.

/Severin

Hi all,

A lower score than Krishnan Y N

but passed anyway!!!

I passed HF-EJB 2 days ago with 74% and thought to pass parhaps with 80% after reviewing my failures....

Great thanks to the HF-EJB team and the support in this forum (Valentin Crettaz, Marc Tedone, Nitin Mehhta, gabriele rigamonti, Giju George, Vinicius Boson ...)

Severin

] Can Home Business method return an EJB Object reference?

Why not?

spec 10.6.6:

If the ejbHome<METHOD>(...) method corresponds to a home <METHOD>(...) on the entity
bean�s remote home interface, the method argument and return value types must be legal types for
RMI-IIOP.


Severin

yes, that's correct. Notice that "passivation" in Entity Beans is not the same as passivation in Stateful Session Beans. For Entity Beans it's only a "change of their role", not a "swap out to disk", although their state may be written to the disk too in ejbStore().

Severin

Hi Catalinescu,

In my opinion, you can be a "experimented J2EE Programmer" (whatever experimented in details means ;-) even if you don't know EJB. Your application needs may fit exactly into the J2EE technologies without EJB's. I, for example, have a few servlet / JSP experience, no experience in Webservices and a lot of experience with EJB's.

However, EJB is not only a relational mapping tool. EJB is much more, and in our project we don't use this part of the EJB technology - we don't use Entity Beans. The main adventages of EJB's are (maybe this is an incomplete list - other opinions are welcome):

- Transactionservices
- Securityservices
- Single-threading model for the Bean Provider (=Programmer)
- Portability
- Messaging integration
- Timer services (singe EJB 2.1)
- relation mapping tool ;-)

Severin

such questions will not come up.

Severin

Hi Sabari,

The point is the following:

(1) Storing something in the database means:

UPDATE data_info SET TITLE='Volcanos' WHERE ID = 100005; (=ejbStore)

(2) finishing a transaction means:

COMMIT

After (1) is running nobody else can see a change on the database until (2) runs (depending on your isolation level). The container may passivate your bean between (1) and (2).


Hope this helps

Severin

hmmm - what's the default isolation level? READ_COMMITTED I think? If your messages rarely change the same data I would'nt have fear that there are too many rollbacks, if any. We serialized because there was a application dependency between some messages.

Severin

Hi Stephan (chasch d��tsch? ;-)

I thought XA is only necessary when you have transaction running on more than one application server? Am I wrong?

Yes, you're wrong. As soon as you have one single transaction distributed over two different data sources, you need XA. How else can the container assure that the Transaction (for datasource DB and for datasource MDB) is committed at the "same" time?

Question: which attributes did you set? The correct settings for your problem are (in my opinion):

- SLSB CMT RequiresNew
- Entity Bean: CMT, Required
- JMS: transaction: true, ack-method 0

See also J2EE Tutorial Managing Distributed Transactions:

When you create a session in an enterprise bean, the container ignores the arguments you specify, because it manages all transactional properties for enterprise beans. It is still a good idea to specify arguments of true and 0 to the createSession method to make this situation clear:

session = connection.createSession(true, 0);

When you use container-managed transactions, you usually specify the Required transaction attribute for your enterprise bean's business methods.



/severin

How do you get your QueueConnectionFactory / Queue? Through the container, I guess?

Did you specify the transaction behaviour of your JMS-Session as "transacted"? (Argument true)?

... my solution was to start an external process that consumes the message and call's a method of an stateless session bean. Failover was not nescessary because we did monitor the queue (alert if the number of messages pass a limit).

Severin

do you have a cluster? then each cluster member will have an instance and your approach does not work in this case...

If you use static methods in a helper class there's no problem. If you use static methods in your bean class directly there could be a problem, depending on your container implementation. The countainer is allowed to subclass your bean and could miss to take in count that you could made a static class.

Remark: don't use static members in helper classes!!! (they have tha same effect as in your bean class).

... yes, the confirmation is in

21.4.3

If the Application Assembler specifies that a run-as identity be used on behalf of a particular enterprise
bean, the Deployer must configure the enterprise beans such that the run-as principal is used as the
caller principal on any calls that the enterprise bean makes to other beans, and that the run-as principal
is propagated along the call-chain of those other beans (in the absence of the specification of any further
run-as elements).

/Severin