• Post Reply Bookmark Topic Watch Topic
  • New Topic

Pending session bean

 
Alec Shcherbakov
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a stateless session bean that interfaces a legacy application by calling some method. Legacy system may be down or experience overload in which case the session bean doesn't get a response back during some significant amount of time.
Currently I use a utility object that gets an instance of the session bean, creates a thread which invokes the above method that calls the legacy application, and immediately after starting the thread issues method on the thread. If the thread is still running when timeout occurs, utility object returns to its caller with a custom exception "TimeoutException".
Now, the question is: what to do with the pending session bean's method call? As I understand, bean's instance would be still alive until it's invoked method returns. In case of a large number of requests and if the legacy application is not responding there could be a growing number of useless bean instances, which could result in memory shortage and EJB container overhead.
Is there any suggestions on solving this problem?

[ February 04, 2004: Message edited by: Alec Shcherbakov ]
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alec Shcherbakov:
I have a stateless session bean that interfaces a legacy application by calling some method. Legacy system may be down or experience overload in which case the session bean doesn't get a response back during some significant amount of time.

I haven't played around with the EJB timeouts, but couldn't you start a transaction in your session bean (or mark it as "RequiresNew" if you're using CMT) and set the txn's timeout? This way you shouldn't need to create a thread to implement your own timeout. Once the container sees the transaction has passed its timeout, it will terminate it and throw a TimeoutException.
 
Alec Shcherbakov
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Harkness:

I haven't played around with the EJB timeouts, but couldn't you start a transaction in your session bean (or mark it as "RequiresNew" if you're using CMT) and set the txn's timeout? This way you shouldn't need to create a thread to implement your own timeout. Once the container sees the transaction has passed its timeout, it will terminate it and throw a TimeoutException.

I tried this approach, but what is strange I still did not get a response back from the session bean. The only effect I had was a system message in the app.server log notifying that the transaction timed out. That is the session bean seems to keep executing (waiting for response from the legacy).
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is the kind of thing you should handle using JMS and an MDB instead of a Session bean. You should NEVER, EVER spin off your own threads inside EJB's. It espressly disallowed in the EJB spec.
Kyle
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
You should NEVER, EVER spin off your own threads inside EJB's. It espressly disallowed in the EJB spec.

Just to add to what Kyle said... many EJB Containers put all sorts of stuff in ThreadLocals for things like transactioning, security, etc. Creating and managing your own threads could cause many problems in an EJB environment.
[ February 04, 2004: Message edited by: Chris Mathews ]
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
[]This is the kind of thing you should handle using JMS and an MDB instead of a Session bean. You should NEVER, EVER spin off your own threads inside EJB's. It espressly disallowed in the EJB spec.[/i]

As Alec said he is creating a thread in a utility object and then calling the SLSB, I assumed that the thread creation was happening outside the container in a non-J2EE client. If this is the case, all should be okay.
If instead, Alec, you are creating the thread from some other SLSB or container-managed code, that could be the problem.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Harkness:
As Alec said he is creating a thread in a utility object and then calling the SLSB, I assumed that the thread creation was happening outside the container in a non-J2EE client. If this is the case, all should be okay.
If instead, Alec, you are creating the thread from some other SLSB or container-managed code, that could be the problem.

My initial assumption, based on the post, would be that this was indeed happening within the context of the EJB Container. Of course, this is not helped by the fact that many people think that the spec limitations only apply to code which physically resides in the EJB class, not code that is merely called from the EJB class. This is a point of much confusion for many people for some reason. Although, I do agree that it is very possible the thread is being created outside of the EJB Container and that we should probably find out from Alec what exactly is going down.
Regardless, anytime I hear EJB and thread in the same sentence I immediately think of JMS as an alternative.
[ February 04, 2004: Message edited by: Chris Mathews ]
 
Alec Shcherbakov
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Harkness:

As Alec said he is creating a thread in a utility object and then calling the SLSB, I assumed that the thread creation was happening outside the container in a non-J2EE client. If this is the case, all should be okay.
If instead, Alec, you are creating the thread from some other SLSB or container-managed code, that could be the problem.

Correct, I use a utility object. Though this object is created from another stateless bean, I don't think this is a problem as the utility object is located outside the EJB container and so is the thread it creates.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alec Shcherbakov:
Correct, I use a utility object. Though this object is created from another stateless bean, I don't think this is a problem as the utility object is located outside the EJB container and so is the thread it creates.

If it is created from within an EJB then it resides within the context of the EJB Container and hence is breaking the spec by creating threads. This is exactly the type of confusion that I was alluding to above.
 
Alec Shcherbakov
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kyle Brown:
This is the kind of thing you should handle using JMS and an MDB instead of a Session bean. You should NEVER, EVER spin off your own threads inside EJB's. It espressly disallowed in the EJB spec.
Kyle

I know that, but in my case I actually use a thread only as a timeout feature. Thread's run() method contains only a session bean's method call.
Thread starts and if it doesn't end within a given timeout, the utility object throws a TimeoutException back to the calling session bean. The problem is how to clean up all those pending beans that are still alive because of waiting for a response from the legacy system. Or maybe I should leave this to EJB container?
 
Alec Shcherbakov
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Chris Mathews:

If it is created from within an EJB then it resides within the context of the EJB Container and hence is breaking the spec by creating threads. This is exactly the type of confusion that I was alluding to above.

As you mentioned JMS, can you outline how to do that with JMS? I'm new to JMS and would appreciate a word from expert.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alec Shcherbakov:
Correct, I use a utility object. Though this object is created from another stateless bean, I don't think this is a problem as the utility object is located outside the EJB container and so is the thread it creates.

No, this is precisely what Chris meant when he said "many people think that the spec limitations only apply to code which physically resides in the EJB class, not code that is merely called from the EJB class." If you have a SLSB that creates a utility object, and that object creates a thread, you are most decidedly running inside the container and within the EJB context.
I should probably clarify that. It *is* possible that the initial SLSB is creating a utility object, and that utility object is making an RMI call to another non-J2EE server, which then creates a thread. In that case, yes, you would be running outside the container and its context, and creating a thread would be okay. However, that's probably not what you're doing.
The code doesn't have to be in the bean class to be involved in its context. This is good because it allows you to write and reuse utility objects from many beans. If you lookup the UserTransaction from the utility object, you'll get the same one as your calling beans (it's attached to the thread).
In any case, it's odd that your transaction isn't truly timing out. It should interrupt the SLSB and throw a timeout exception.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!