Because you are asking for "real time" response processing from EJB
when it is not designed as a "real time" system.

You would have to write your own timer.

If you don't mind being jboss-specific, you can write your own client
interceptor to avoid changing the code.
This processing certainly cannot be done in a portable fashion.

Regards,
Adrian

Depending on your problem/flexability to change the code, you could wrap your process with a stateless session bean (SLSB). SLSBs do support the construct of "timing out" a supposed "session". Whose to say exactly what a session might be comprised of. You might be able to work SLSBs into your solution... but that does involve making some changes to your application or client code.

If, as you suggested in your initial post, you are constrained to existing client code, then you have to take the path Adrian is suggesting and use interceptors so that the container/environment deals with your issues (since you can not or will not change the client).

Take a class with the JBoss group... it will likely be the easiest way to get things done AND you will have the benefit of personal contacts within the consulting group.

Okay, you don't want to take a class. Here's the short answer...

JBoss is MBEAN and interceptor-centric. That is, JBoss is deployed as a set of dynamic services which you pick and choose with various MBEANS (ala JMX). You edit the XML deployment files to launch the services you want and you connect classes and components within a service via the MBEAN.

You need to grasp this concept before you fo further. Once understood you will find that there is an XML file deployed to control the default interceptors for EJBs. Further, you can provide a similar file with each JAR you deploy with a set of rules and services customized for that set of beans deployed with the JAR that overrides the container defaults. It is in this user-specified XML file that you will specify a new interceptor, or modify an existing interceptor to get the behavior you want.

Take the default standardjbosscmp-jdbc.xml file:

<!-- ===================================================================== -->
<!-- Standard JBoss EJB Configurations -->
<!-- ===================================================================== -->


<enforce-ejb-restrictions>false</enforce-ejb-restrictions>

<invoker-proxy-bindings>
<invoker-proxy-binding>
entity-rmi-invoker
<invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>
<proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
<proxy-factory-config>
<client-interceptors>

org.jboss.proxy.ejb.HomeInterceptor
org.jboss.proxy.SecurityInterceptor
org.jboss.proxy.TransactionInterceptor
org.jboss.invocation.InvokerInterceptor


org.jboss.proxy.ejb.EntityInterceptor
org.jboss.proxy.SecurityInterceptor
org.jboss.proxy.TransactionInterceptor
org.jboss.invocation.InvokerInterceptor

<list-entity>
org.jboss.proxy.ejb.ListEntityInterceptor
org.jboss.proxy.SecurityInterceptor
org.jboss.proxy.TransactionInterceptor
org.jboss.invocation.InvokerInterceptor
</list-entity>
</client-interceptors>
</proxy-factory-config>
</invoker-proxy-binding>

In this snippet, notice that there is a section for the <client-interceptors> and the interface. You can modify/extend an existing interceptor or you can add your own interceptor and use that in place of the containers default interceptor. The way you replace the containers behavior is by naming your interceptor differently and plugging that into the MBEAN/XML file that is deployed with your JAR. This way, the container will defer processing to your interceptor for the specific BEAN(s) and use the container default for everything else.

I would suggest getting someone to help you under a consultation arrangement as this will get you through the hurdles quickly. Your solution will depend on what exactly it is you want to time/timeout. The person coding up/designing your solution will need to understand your application and problem in detail in order to provide the right solution (code).