Skip to main content

Internal processes in EJB

9 replies [Last post]
rpolozov
Offline
Joined: 2003-07-15
Points: 0

Hello,

I am new in JEE technology and cannot find answer to my question.

I want to create JEE application, what should not only process requests from web-client,
but should also periodically request some special hardware and update database, based on the answers. So, could you give some recommendations regarding possible architecture.

Is it Ok to create threads from Session Beans?
Is it possible to create new threads from Session Beans?
Is it Ok to open from Session Beans server sockets to listen incoming requests?

Is it possible to use EJB TimerService instead of separate threads (it read that this service is better to use for long tasks, but my tasks are very short and should be repeated every second, for example)?
If yes, is it possible to store current context of the pooling in some place (Stateful Session Bean for example)?

Best regards,
Roman

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
whartung
Offline
Joined: 2003-06-13
Points: 0

This sounds like a JCA use case to me, as that's really it's role -- integration of the JEE container with external systems (which is basically what you're doing).

The Stateful Beans are not really appropriate for your data storage, as Stateful Beans can not be shared across clients.

While an arbitrary client can get the Stateful Bean handle, in order to locate the Bean, and that handle can be shared, actual access to the Stateful Bean can NOT be shared. Specifically, if more than one client tries to access the Stateful Bean at the same time as another client, you will get an exception.

So, as a source of shared knowledge, the Stateful Bean is not the best component. It's really designed to handle the state for a single client.

If you're not running in a clustered environment, it's perfectly acceptable to use (for the time being) a static instance variable, as part of perhaps a Session Bean, to store your monitoring data. You will need to synchronize access to this shared resource yourself, but that's ok.

Write a JCA module that sends the raw monitoring data to an MDB (through a JMS queue). The data is maintained as a static member of a session bean. The MDB can call service methods on that session bean, and then the clients can also call that session bean. Of course if the session bean needs to persist anything to the DB, it can do that as well.

If you're in a clustered environment, then you'll need to explore some kind of shared cache implementation.

rpolozov
Offline
Joined: 2003-07-15
Points: 0

Thank you for information!

Theoretically it could be clustered environment.
Could you recommend some shared cache implementation for GlassFish?

Best regards,
Roman

rajraman
Offline
Joined: 2008-11-18
Points: 0

We have a slightly similar issue.....

we are using JBOSS 4.0.5 GA with EJB 3.0

can we create threads within stateless SB's transaction scope?

the scenario is that the thread that is created internally accesses the entity manager. it does get the em from through JNDI look up but any operation yields this exception

20:52:58,970 ERROR [STDERR] java.lang.NullPointerException
20:52:58,970 ERROR [STDERR] at org.jboss.ejb3.entity.ManagedEntityManagerFac
tory.getNonTxEntityManager(ManagedEntityManagerFactory.java:59)
20:52:58,970 ERROR [STDERR] at org.jboss.ejb3.entity.ManagedEntityManagerFac
tory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:164)

perhaps the transaction scope is not propagated.

we used jdj 1.5's "concurrent package" to achieve parallel processing.

We also tried JBOSS work manager but it falls short of our requirement to wait till all tasks are completed. Later versions of work manager does have this feature. However that requires us to replace core jar files that come bundled with 4.0.5 G, is this recommended?

Its claimed that 5.0 does support such operations. Does anyone have an insight about this issue.

regards

bbergquist
Offline
Joined: 2007-04-02
Points: 0

The EJB TimerService might work depending on if your requirements are truly periodic. The timer service can fire off a stateless session bean method.

If it were me, I probably would write a JCA resource adapter. This is one place where you can create threads or use the Work Manager to manage the threads for you. To communicate back to the standard JEE components, you could use an inbound connection to drive a message driven bean endpoint. The MDB has full capabilities of interacting with other resources like a database, calling other EJB's, etc.

rpolozov
Offline
Joined: 2003-07-15
Points: 0

Thank you!

I do not understand how can I store state of communication process.
I need to store temporary data between consequent call.
As I understand, if I use TimerService, it can call only Stateless Session Beans.
So, different instances of my session bean can be called.
If I inject Statefull State Bean into my Stateless Session Bean, each instance of Stateless Session Bean will have it's own Statefull Session Bean and I can loose my data... How can I be sure that all my Stateless Session Beans use just one instance of Statefull Session Bean?

As I understand, I will have the same problem, if I use JCA resource adapter and MDB.
Is it correct?

Could you recommend some article or book where it is better to read about writing JCA adapters?

Best regards,
Roman

bbergquist
Offline
Joined: 2007-04-02
Points: 0

A couple of articles:

http://www.javaworld.com/javaworld/jw-06-2005/jw-0606-jca.html
http://www.theserverside.com/tt/articles/article.tss?l=J2EE1_4
https://www6.software.ibm.com/developerworks/education/j-jca/j-jca-pdf.pdf

Book
J2EE Connector Architecture and Enterprise Application Integration

Can you explain a little more about what you are trying to do and maybe I can help a little more. Your initial question indicated that you wanted to periodically query a device and update a database. Querying the device can be done by having threads (WorkItem) in the adapter and updating the database can be done by invoking an inbound endpoint which will implemented by a MDB which can then update the database. An adapter is also a good idea if you are going to use a communications protocol such as TCP or UDP to communicate to your device.

For example, I have written an adapter that communicates with our network equipment. It receives test measurement updates using UDP and then invokes an endpoint with the test measurement data, which invokes an MDB that stores the information in a database.

One thing about an adapter. On an outbound connection call, (think something like using a database connection), the adapter has available the environment of the calling component. That is, it can access SSB, JNDI, etc that the calling client component has. Once the call is complete the adapter does not have this environment anymore. So it is not easy or apparent how to have an adapter access back into the JEE components such as SSB, etc. The key here is to invoke an endpoint and the MDB that is connected to the endpoint has all of the capabilities to interact with other JEE components, JNDI, etc.

rpolozov
Offline
Joined: 2003-07-15
Points: 0

Thank you for your answer!

I have set of special hardware what I need to poll periodically by TCP/UDP/Serial Port/... to get it's current state. That state should be displayed in "real-time" on clients. At any time any client can also send to any peace of hardware some commands, that should be sent to that hardware in real-time also. Some hardware can send it's status by TCP or UDP directly. In that case I need to open server socket and listen for that information.
Of course I can separate all work with hardware from container to separate application, but I would not like to do this, if this is possible.
So, my tasks look close to your.

I am familiar with CORBA technology, but JEE is new for me.
I plan to store status of the hardware in set of statefull session beans.
But this set should be common for all clients. As I understand, by default any client (stateless session bean, MDB, application...) has it's own instance of session bean.
This will prevent exchange of information between them. How can I use common set of beans for all clients or what is recommended way to synchronize they're state?

Thank you in advance!
Best regards,
Roman

bbergquist
Offline
Joined: 2007-04-02
Points: 0

statefull session beans are not meant to be used in this manner. They are used to maintain across a "conversation" with one client, not to be shared between clients. A good example might be a "shopping cart" which is used to maintain the contents of what you have ordered until checkout time. Two different customers would not share the same "shopping cart".

From what you are describing, I would probably build one or more resource adapters to handle the communications requirements with the special hardware depending on the communications mechanism. It could be one to handle all, or one to handle each.

You mention "real-time" by the client. Is this "near-time" in that the client would look at stored state (say a database) and the state would be updated periodically, or would the client request the state "on demand". Both can be done.

The first way would be to have you resource adapter poll the equipment and invoke an endpoint that drives an MDB to store the state in the database.

The second way would be to create an outbound connection interface (could be proprietary or could be using the Common Client Interface) and allow a client to "connect" to the resource adapter and acquire state on demand by actually querying the equipment right then and there. Picture your equipment being an SQL database and your clients using a "connection" to query it. The same type of setup can be done where your "connection" actually talks to live equipment.

To have your clients retrieve the information, you could use JPA and make the data Entity beans. These would be shared among clients.

rpolozov
Offline
Joined: 2003-07-15
Points: 0

Thank you for information about JPA. I think that is what I need.

When I said 'real time' I meant that client should have possibility to ask current state of the hardware at any time and result should be received in not more then 1 sec.
Hardware can send message about state changing at any time and this message should be delivered to all clients in not more then 1 sec.
Status of the hardware can be changed very often. It could happen each second for some hardware objects. Total load is several tenth or hundred messages per second.
Client can send commands to hardware objects also. So, in any case I need to implement direct hardware request by demand.

Best regards,
Roman