Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB

 
Soman Singh
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Tejpal Singh
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Soman Singh
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again,
What are the methods of JTA?
 
Soman Singh
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again,
What are the methods of JTA?
 
Soman Singh
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Lasse,
Thanks for the answer but was not very clear with the same.
Can you elobrate bit more.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic