1. Can we make Session Bean Persistent. What I mean is we make a database connection and fetch the records.
Why you want to do that Soman? EJB provides the Entity Beans for that... Still, you may instead consider creating a Java DAO for accessing the database. Do rembember to pool the connection to the database in that case.
Originally posted by Soman Singh:
2. Why does pooling concept not applies to Session Bean?
Pradeep, I guess stateful session beans don`t provide pooling, that is if you have 1000 users on your server, you have also 1000 session beans instances running ! Is there anyway that they can be pooled? weather database or instance?
"When work, commitment and pleasure all become one and you reach that deep well where passion lives, nothing is impossible."
Tejpal, I do not know any server that provideds stateful session bean pooling. It is not worth pooling SFSB. Here is what Chris Mathews had to say in one of the previous threads
It is technically possible to pool instances of Stateful Session Beans but it doesn't make much sense and the context switch would kill performance.
Joined: Sep 02, 2003
In case we have instance pooling with Stateful Session Bean, will the memory be in trouble. The number of bean instances we make shal be swapped out on disk when not in use and that holds true for every Bean. Some Confusion here .... Thanks !!
In case we have instance pooling with Stateful Session Bean, will the memory be in trouble. The number of bean instances we make shal be swapped out on disk when not in use and that holds true for every Bean.
The fact that all of those -- possibly thousands of -- bean instances don't fit into the memory the same time is exactly the cause for the performance handicap of pooling stateful session beans. Reading and writing stuff to disk is often several magnitudes slower than instantiating objects.
Originally posted by Soman Singh: Hi again, What are the methods of JTA?
Joined: Jan 23, 2002
Let's say your application has 10,000 simultaneous users each doing something that requires the use of your stateful session bean. A lot of traffic, a lot of client-specific data. Now, you can't loose any of those 10,000 session's data, right? You have two choices: create and keep all 10,000 instances of the stateful session bean in memory, or only keep a limited number of beans in memory at a time while persisting the other sessions into disk. The first alternative is certainly faster but you really can't keep everything in memory, so the second alternative is more appropriate. The second approach, keeping only some of the sessions in memory, has two main implementation approaches: write the whole bean instance into disk when needed, or reuse bean instances with an object pool and only write the object's state into disk. Let's say that the application server is pooling stateful session bean instances. In practice, this means that for every incoming request for a stateful session bean of type MySampleSFSB, the container must do the following: 1) Pick an instance of MySampleSFSB from the pool 2) Read the client-specific state from somewhere (database/filesystem) 3) Assign the client-specific state to the MySampleSFSB instance 4) Let the instance execute the business method 5) Detect whether the bean's state has changed and write it into somewhere (database/filesystem) 6) Return the instance back into the pool The cost of steps 2, 3 and 5 probably exceed the benefits of pooling the instances.
But isn't that precisely what stateful session beans do? Or what a J2EE container author might be allowed to make them do? I confess little hands-on experience here, but my class notes (from IBM WebSphere 5) have a life cycle state transition diagram showing sfsb doing things like this: does not exist -> create -> method ready pool -> call methods -> passivate -> passive pool -> activate -> method ready pool -> etc. Your steps 2, 3 and 5 are passivate and activate, no? And yes, they sound expensive! BTW: Other branches: method ready pool -> EJBRemove -> does not exist passive pool -> time out -> does not exist
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 23, 2002
Your steps 2, 3 and 5 are passivate and activate, no? And yes, they sound expensive!
Basically yes. The difference between pooling or not pooling would mean that the container has to do a1) Pick an anonymous instance from an object pool a2) Load state from disk and populate the instance variables a3) Delegate business method invocation a4) Store state to disk a5) Return instance to object pool instead of b1) Load instance + state from disk (or create to initial state) b2) Delegate business method invocation b3) Store instance + state to disk If you think of it, there isn't much performance difference between "a1 + a2" and "b1". [ September 04, 2003: Message edited by: Lasse Koskela ]
Joined: Jan 29, 2003
Thanks! It would be nice if we could trust that Sun did their homework, tested both techniques and gave us the fastest, most efficient one. And not just what looked coolest on architecture diagrams. I did a J++ COM web server with a rather complex graph of objects that we serialized and de-serialized (or vice versa) on every request. Fortunately it had very few users. Whew. And I didn't do it again! But that experience makes me appreciate what J2EE can automate for us!