EJB vs. Object Pool

[John Dunn]

I currently use ojbect pools, (~30K composite objects, 20 total in pool), to transactions and no security issues. (I need large StringBuffers to capture xml inquiry, build xml response, compress response, etc.)

Is there a point to use EJB here? We use the object pools b/c we REALLY need speed. Unfortunately, although we get speed, we also get a nice memory leak from the pools. We currently are hitting 2million req per day and should eventually hit 3mil.

I guess my real question is: Can EJB be used solely as a way to re-use memory? Are there third party Ojbect pools that I would benefit from more instead?

Thanks for any help!

[Rahul Bhattacharjee]

I do not know mcuh about EJB's.But still I would like to put my view regarding this.Please correct me if I am wrong.

Apart from pooling of the beans , EJB provide many functionalities and transaction support to the application.It should be carefully used in application , which would really use a lot of features of EJB ,not just for pooling.
If only used for pooling then normal pooling would be better than EJB's.

[William Brogden]

we also get a nice memory leak from the pools.

What have you observed that makes you so sure it is the pools that are causing memory leaks?? After all, there are plenty of other ways to "leak" memory.

Bill

[John Dunn]

Hi Bill.

A long time ago, we removed all creation of objects that occur during an Inquiry/Request pass. So we basically we have everything we need up front. I'm pretty certain our problem lies in the final
StringBuffer.toString() call that creates underlying new objects, AND on the opening of Streams to pass data back to a client. I don't think these composite objects we use to store all our needed objects, get gc-ed b/c, the pool of objects never die. I'm using iPlanet 6.0, and they warn you against using pools, but we absolutely must have the speed, so we were willing to live with the trade offs. Well as much as I need the speed I also need to consider handling another 1 million requests, so I'd like the same speed with a set up that can correct g/c the shared objects I use.
Could Spring help out here?

[William Brogden]

I'm pretty certain our problem lies in the final
StringBuffer.toString() call that creates underlying new objects, AND on the opening of Streams to pass data back to a client. I don't think these composite objects we use to store all our needed objects, get gc-ed b/c, the pool of objects never die.

toString() creates just one String - assuming thats a local variable it will be eligible for GC as soon as the method exits. Are you sure Streams are closed correctly?

How do you provide for reseting variables in a pool object when it has finished a response?

Bill