wood burning stoves 2.0*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Entity beans are shared data? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Entity beans are shared data?" Watch "Entity beans are shared data?" New topic
Author

Entity beans are shared data?

Aniruddha Bapat
Greenhorn

Joined: Jun 07, 2002
Posts: 3
q. When two clients invoke a finder method which is going to return same row in db if only one entity bean is activated by container or two?
q. When a client has invoked a finder method for which a entity bean is activated;
When other client invokes a finder which will return the same row a new bean is activated
or reference to existing bean is returned?
thank you people in advance..
Alex Zhang
Ranch Hand

Joined: Apr 19, 2001
Posts: 68
As I know, the actual number of bean instance is vendor specific but entity bean can be accessed by multiple client. So It may be single or multiple for the entity bean instance, whereas to the remote object of the entity bean, every client should have their own proxy object to that bean.
Alexander Yanuar Koentjara
Ranch Hand

Joined: Jun 03, 2002
Posts: 31
From Mastering EJB (Ed Roman), it is stated that one Bean (entity/session) can only serves 1 client at one time. So if there is 2 clients request the same bean (same PK) at the same time, the container will have at least 2 beans and 2 EJBObjects. If a bean is shared by more than 1 client at the same time, then it will be impossible to call context.getCallerPrincipal(), right?
I am not sure for Message-Driven beans since they are not directly accessed by client.. but I think one MD-bean should only be used by one thread at one time.. if not .. then it will be painful and hard to synchronize the transactions.
[ June 12, 2002: Message edited by: Alexander Yanuar Koentjara ]

===================================<br />Fear not, God know the best.<br />SCJP2 91%<br />SCWCD 89%<br />SCJD2 92% (143/155 pts)<br />SCEA Part I (89%)
Alex Zhang
Ranch Hand

Joined: Apr 19, 2001
Posts: 68
Quote from J2EE Tutorial
What Is a Session Bean?
"As its name suggests, a session bean is similar to an interactive session. A session bean is not shared--it may have just one client, in the same way that an interactive session may have just one user..."
What Is an Entity Bean?
"What Makes Entity Beans Different from Session Beans?
Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared access, have primary keys, and may participate in relationships with other entity beans.
...
Shared Access
Entity beans may be shared by multiple clients..."
I think what you concern or we concern is how the entity bean presist data, if it is CMP, the persistence job is handled by the container, and what I experience is whenever I call the set methods, it presists, and when I have lock the record by other means, the operation suspends.
And with BMP, it persists whenever the ejbStore method is invoked, so I think it is not so critical that the container will handle such jobs for us.
Sanjay Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 148
All,
Good conversation so far...My 2 cents on the topic.
Concurrency: Enterprise Beans are not inherently concurrent. This means that they can never be shared concurrently.
With Session beans that is easy to understand. Session beans are like an extension to the client. SFSB maintain conversational state, so they can't obviously be shared.
SLSB only service a client for the duration of the method. Further any SLSB instance in the pool (of the same class, obviously) is equivalent to any other (note while in the pool they are not servicing requests.) So another concurrent request to the same service gets it's own instance of the bean.
Now with Entity beans the story is a lot different. After all, they are supposed to represent shared data. Here's the trick. Only one bean instance will represent the same row in the database. You cannot have two bean instances pointing to the same row. That would clearly violate all ACID properties.
What happens here is that two clients requesting the same row both end up getting a reference to the same EJBObject. Note however that only one client thread will be allowed access to the instance at any given time. If the methods are non-tx in nature, after one client's method has executed, the container gives the thread to the next client. If the methods are tx-methods, then the container will consider the transactional context before giving the thread to the next client. Further isolation levels also play an important role here...if you're using serializable then Dirty Reads, Non-Repeatable reads and Phantom reads are all addressed.
Now this may sound like it makes entity beans slow. And it does. But that's where you use good archietcture / design. If you are primarily dealing with read only data, the trick is to use a Session Bean with a DAO. Unless your operation involves deletes and updates to the same row (note: not the same table) concurrently, Entity beans may not always be the best bet.
E.g., if you are dealing with a customer mgmt app, and assume that online customers can view / modify their own records. Session beans with DAOs are decent candidates, although Entity beans can be used equally appropriately as well.
Now consider an online aution site. Many customers bid on the same object. The same row can concurrently be modified by more than 1 person. There is no doubt that this is a job for Entity beans. Session beans are are definitely not as appropriate.
HTH.


Sanjay Raghavan<br />SCJP2, SCEA-J2EE<br />Moderator - <a href="http://groups.yahoo.com/group/scea_prep" target="_blank" rel="nofollow">SCEA PREP</a><br />Co-Author - <a href="http://www.whizlabs.com/scea/scea.html" target="_blank" rel="nofollow">SCEA@Whiz</a><br /><i>Where did you sip your Java Today?</i>
JiaPei Jen
Ranch Hand

Joined: Nov 19, 2000
Posts: 1309
Hi, Sanjay:
If you are primarily dealing with read only data, the trick is to use a Session Bean with a DAO.

Do you think we should use a Session Bean and a VO instead of DAO?
Sanjay Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 148
Data Access Object: Allows for clean separation of business logic and data access logic inside the enterprise bean.
So you may use 1 session bean which can delegate the data access functionality to the appropriate sub-class of the Abstract DAO class (or interface as the case may be), obtained via a DAO factory for database specific needs.
Value Objects: Important from the point of understanding coarse-grained access vs. fine grained access.
Remember that in EJB 1.1 there was no concept of a "local home" or "local component" interface. (BTW we call the remote interface component interface in EJB 2.0 because "local remote" sounds confusing.) Also remember that the best practices recommended the use of a Session-Facade to access Entity beans. This meant remote calls to every getter and setter methods in the Entity bean. To avoid that latency, they recommended value objects to encapsulate the entity bean's data so that the session-facade made only one call to the entity bean and allowed the client to use different getter and setter methods on the VO instead.
So to put all this diagramatically, you would have:
client(browser)-->front controller(servlet)-->business delegate(java bean/class...not ejb)-->session facade(session ejb)-->value object(java class)-->entity ejb-->dao(if used with bmp)-->jdbc-->database.
HTH.
JiaPei Jen
Ranch Hand

Joined: Nov 19, 2000
Posts: 1309
I am thinking about accessing EIS tier for "read-only" purpose. A session bean with a VO would be suitable. Do we use a session bean with a DAO for read-only data?
Sanjay Raghavan
Ranch Hand

Joined: May 14, 2002
Posts: 148
Absolutely....
The DAO is the EIS integration tier in this case. Suitable for both Session Beans and BMP entity beans to access the db.
As I explained earlier, by definition VOs only encapsulate the entity data so you may do fine grained access. Again with EJB 2.0 (local interfaces) the use of VOs may diminish with Session-Facades.
DAOs decouple the bean code from the data access code so that different data access code may be used with the same bean.
For example assume that you are developing an EJB service that can work on any RDBMS. Assume also that outer joins have different syntax in Oracle and Sybase.
Two customers buy your EJB service. One has an oracle db where the tables required for your service will be created. The other has a sybase db where the same will be done.
How would you code your SQLs now. Not in the bean class because the same class has to service two different dbs. The answer is to have an abstract-service-dao declared in the bean that receives delegated requests.
We will have two concrete-service-dao classes for the two dbs. con-ser-orcl-dao and con-ser-syb-dao. They will have unique select statements (or insert / delete / update) as the case may be.
A factory will get you the instance of the appropriate concrete-dao. Your methods will work independently of implementation.
If you are essentially doing the same thing, then you are using the concept of DAO and just calling it VO.
HTH.
JiaPei Jen
Ranch Hand

Joined: Nov 19, 2000
Posts: 1309
Thanks for the explanation. I like the discussion.
Alex Zhang
Ranch Hand

Joined: Apr 19, 2001
Posts: 68
For me, the value of Entity Bean or considering using it is the power of transaction and persistance management, and it is what the spec wants J2EE to provide to the user (the developer). So, when someone say "I am going to use Entity Bean", most likely I would think they have considered the benefits and the power of Entity Bean over other methods like Session Bean + Data Access RowSet. Surely entity bean is not a total solution for data access unless we don't have so many patterns in this field. But what I hold is when we choose to use it, we should take less consideration over data persistence and transaction management. Do you agree?
Alex Zhang
Ranch Hand

Joined: Apr 19, 2001
Posts: 68
Hey BTW, Do you think Javaranch should use java technology for this web instead of using cgi?!
I think it is not good for a group of Java supporters to use non-Java technology to discuss Java technology.
I must be the 1st volunteer to take part in the design and implementation if it will be migrated to Java platform. Or we should take a look at theserverside.com!!! :roll:
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Entity beans are shared data?