Meaningless Drivel is fun!*
The moose likes EJB and other Java EE Technologies and the fly likes EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB" Watch "EJB" New topic
Author

EJB

Soman Singh
Ranch Hand

Joined: Sep 02, 2003
Posts: 37
Hi Folks,
I am new to EJB.
So some questions would sound silly.

1. Can we make Session Bean Persistent. What I mean is we make a database connection and fetch the records.
2. Why does pooling concept not applies to Session Bean?

Thanks in Advance,
Sos
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904


1. Can we make Session Bean Persistent. What I mean is we make a database connection and fetch the records.

Yes, you can access datbase from Session beans using JDBC.

2. Why does pooling concept not applies to Session Bean?

Are you talking about instance pooling or datbase pooling? Stateless session beans can be pooled.


Groovy
Tejpal Singh
Greenhorn

Joined: Aug 08, 2003
Posts: 26
Originally posted by Soman Singh:

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."
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

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.
Soman Singh
Ranch Hand

Joined: Sep 02, 2003
Posts: 37
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 !!
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Soman Singh
Ranch Hand

Joined: Sep 02, 2003
Posts: 37
Hi again,
What are the methods of JTA?
Soman Singh
Ranch Hand

Joined: Sep 02, 2003
Posts: 37
Hi again,
What are the methods of JTA?
Soman Singh
Ranch Hand

Joined: Sep 02, 2003
Posts: 37
Hello Lasse,
Thanks for the answer but was not very clear with the same.
Can you elobrate bit more.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

http://java.sun.com/products/jta/jta-1_0_1B-doc/
Originally posted by Soman Singh:
Hi again,
What are the methods of JTA?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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 ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: EJB
 
Similar Threads
EJB 3 Local Lookup not working with Weblogic 10.3 and JDK 1.6_05
Maintaing everthing in Session Object
Session bean without EJB environment
Ejb
Manually delete entity bean in memory?