Brian Tinnel

Are you asking if it is legal for an EJB to call a Web Service? If so, then the answer is yes.

Listening on a socker is a big no-no within a bean. Creating an outgoing socket is okay.

Are you sending all 1GB worth of data at one time, or is it multiple pieces of smaller sized data. If it is smaller data then you could maybe look at using JMS. The clients can just put the data on a queue and you write an MDB to process it. It is really hard to say if this is workable.

I wouldn't give up on Web Services so quickly (unless you are really sending the 1GB worth of data). For communication between different companies it has a lot of benefits. For one, you don't have to require that they have the jars needed to communicate with your app server.

Not sure if this is causing the problem, but you don't want to have a qconnect.start() in your session bean. start() is used to cause the connection to start receiving messages from the queue and is not needed if you are putting messages on the queue. However, I doubt that it is causing the problem you are seeing.

The only other thing I can think of is to make sure that your transaction attributes are all appropriate. In your case, the session bean and message bean should probably be "Required".

Finally, are you sure that there isn't another client listening to the same queue.

Is jndiContext kept? The spec says that only the environment context is serialized. A new InitialContext() is not the environment context is it? wouldn't you need to have to do a lookup of "java:comp/env" to get the environment context?

Look at pg. 251 of the spec. When ejbPassivate is called, the instance is still connected to an entity object so it can obtain the EJBObject reference and a reference to the primary key.

Won't cause a problem. If you don't need it, don't save it.

If UtilEJB is state then you could have a problem with a stateless bean as a wrapper around a stateful bean. I encountered a problem with this because under JBoss the stateful bean was passivated after 10 minutes of inactivity, and then removed after 30 minutes of inactivity (I think those are the right numbers). So, when my app was idle for more than 30 minutes, attempts to access the stateful bean from the stateless one failed.

For number 2, one thing I have done is to put a timestamp in the table. Then the queries look for configuration that is less than or equal to the current time. If I don't want a config setting to take effect for a day or two, I just set the timestamp to the future. I have also used version numbers, but that is a bit trickier because you need some way of telling the beans which version to use.

Something else to be careful of... If one method calls another in the mega SLSB and you change it so that it needs to call one of the other SLSB then you could have transactional mixups.

For example, if MethodA calls MethodB and both are set as RequiredNew, there is only one transaction created, namely the one for MethodA. That is because calls from one method to another are not intercepted by the container. However, if you move MethodB to a different SLSB, then you call will not be a simple MethodB() call but rather slsb2.MethodB(). In that case, a new transaction will be created. This has both performance and functional implications.

On #1, If UtilEJB is stateless then calling create during ejbCreate should be fine.

On #2, My preference would be to put the configuration information in a database table and use that during initialization. If you want to update the table and don't want your bean to use the new information, there are ways to do that. But, if you must use a file.... Reading it during ejbCreate, doesn't guarantee that a change will not be reflected until restart. Let's say you change the file. Any MDBs currently in the pool will be using the old values. But, if the server needs to create new entries in the pool, they will read the new values. In that case, a Singleton is probably your best bet.

Assuming you are calling MethodB and MethodC directly from MethodA, then it doesn't matter what the transaction attributes of MethodB and MethodC are because they will not be used. Only calls to MethodB and MethodC that go through the Remote/Local Interface will have the transactional semantics applied.

I would think that after calling ejbActivate, a container would next need to call ejbLoad before any business methods could be used. I think the spec only says that the container should call ejbLoad whenever it needs to in order to synchronize with the database. JBoss shouldn't rely on a bean in the pool being in the proper synchonization state.

I think the only difference might be performance. I don't believe that the end result would be any different from a transaction standpoint.

I have done something similar using an MDB to forward a message to Axis. After extracting the envelope, I do a JNDI lookup to get the Axis engine and then I pass the envelope to it for processing.

Let's say you have a Stateless Session Bean with two methods methodA and methodB. Both have RequiresNew as their transaction attribute.

If a client calls methodA or methodB, then a new transaction will be started (because of the RequiresNew). However, if methodA calls methodB directly, a new transaction is not created. That is why the other person probably created a new object, so that the call to methodB would get it's own new transaction.

A simpler method of doing that would be to use the getEJBObject method of the SessionContext to object the remote interface, or getEJBLocalObject to obtain the local interface and use that interface to call the other method. That way the container will intercept the call and do the necessary transactional actions.

For example. If I have a remote interface called TestRemote and my ejb class is called TestBean I could do this:
((TestRemote)context.getEJBObject()).methodB();

The returned collection will be empty (size() == 0) when nothing is found.

If you really want a null if the collection is empty you could just change you session bean code from

result = this.convertTeamsCollection(tmp);

to

if (tmp.size() > 0) { result = this.convertTeamsCollection(tmp); }