How to model entity bean out of this?

[Maulin Vasavada]

Hi all,
I am new to j2ee and I have not coded a single line so far. (Well I just started on j2ee 2 days back ). I have a question about entity bean,
I am trying to convert the application from webserver based to j2ee and I am trying to see which objects I can model as entity beans and how...I am just writing
down as I think along...
- I have a collection (not neccessarily collection framework objects) of ITEM objects that is named as ITEM_COLLECTION
- Now, there are two possible access points for this ITEM objects.
1. From the end user browser where user will see these ITEMS object in a particular ITEM_COLLECTION and
2. From the admin interface where these ITEM objects can be modified (that interface is in jsp/servlet) for a particular ITEM_COLLECTION
- I am thinking of modelling this ITEM object as entity bean BUT I am confused about how exactly it would work the way I want.
If I create entity bean for ITEM object then ejbCreate() will try to insert the ITEM in database everytime I obtain the reference to the bean, right?
Also, if I write a session bean to query those ITEM entity beans via its HOME interface where it doesn't have to invoke ejbCreate (I guess so) then it might work BUT when the admin interface wants to edit an ITEM that already exist as entity bean in appserver then what happens? Do the appserver returns new reference for to ITEM entity bean which is different than already existing ITEM bean instance in appserver? If that happens then there will be this data consitency/synchronization issues right? (OR Transaction Mgmt for entity bean would help here? I amnot able to understand Transaction Mgmt for Entity beans yet )
I might sound wordy or disoriented but I guess that can be forgiven as learning curve on j2ee....
Any pointers to modelling this would be of great help in getting my ideas clear about "what is what and how"...
Thanks
Maulin

[Maulin Vasavada]

I have one more idea...
As the end user interface can't modify my ITEM object, I can just store "serialized ITEM object" in appserver and let admin interface directly work with ITEM entity bean...HOw about that?
Thanks
Maulin

[Maulin Vasavada]

alirght..
I seem to get it. Entity beans are "shared". So the transaction mgmt would do the job I want and I can go with that "Serialized ITEM Object" return which is not an Entity bean...
slowly I'm getting it. Actually, I had this cache thing in mind which led me to confusing entity bean beliefs. I wanted to cache those ITEM objects so that my application doens't result into querying the whole database all the time but I guess that can be solved now as Entity beans for the corresponding ITEM object (or ITEM_COLLECTION however I model it) would be pooled. hence cached...
Still, I would welcome any input regarding j2ee concepts I am missing here to consider.
Regards
Maulin

[Vishwa Kumba]

Originally posted by Maulin Vasavada:

If I create entity bean for ITEM object then ejbCreate() will try to insert the ITEM in database everytime I obtain the reference to the bean, right?

NO. You call entity bean's create() only once to insert the record into the table. Afterwards, you use find() method to retrieve a reference to an existing entity bean.

[Vishwa Kumba]

Originally posted by Maulin Vasavada:
I seem to get it. Entity beans are "shared". So the transaction mgmt would do the job I want and I can go with that "Serialized ITEM Object" return which is not an Entity bean...
slowly I'm getting it. Actually, I had this cache thing in mind which led me to confusing entity bean beliefs. I wanted to cache those ITEM objects so that my application doens't result into querying the whole database all the time but I guess that can be solved now as Entity beans for the corresponding ITEM object (or ITEM_COLLECTION however I model it) would be pooled. hence cached...

Maulin,
I don't think there is any built-in caching for entity beans. Beans in the pool can be used to load the same record or a different record from the database, everytime the client accesses an entity bean. Pooling is used for bean instance management more like the Flyweight pattern.
Before getting into your design you may need to understand the differences between Session and Entity beans thoroughly.
One of my favourite EJB books is ....
http://www.theserverside.com/books/wiley/masteringEJB/index.jsp
[ February 19, 2004: Message edited by: Vish Kumar ]

[Maulin Vasavada]

Hi Vish
I think I understand the difference b/w session/entity beans but I am little confused about how exactly entity beans would work but its getting clearer every day after discussions and more thinking about how it should logically work
Also, the book you referred to me is great. I read it long back when the older version of the same one was there but still that was whole theory concept to me than. After that I forgot the link and lost the PDF I downloaded so I was looking for this book. The link is really helpful to me. thank you.
Okay, now time for more questions/brainstorming...
1. as you mentioned we will call create() method only once on entity beans. that i get now. Now, I have been generating the IDs for my record depending upon some logic so I guess that before calling create() I must get the new ID for the record and then call create() as otherwise create() can't magically know the ID of the record. By ID , I mean the primary key of the record.
2. on the other issue, I have this ITEM_COLLECTION. I would create entity bean for ITEM within that ITEM_COLLECTION and in my case ITEM_COLLECTION would also be an entity bean. So, while adding ITEM in a ITEM_COLLECTION via admin interface I would know which ITEM_COLLECTION I am adding an ITEM to. In this case, I guess I would have creation of ITEM entity bean embedded in the ITEM_COLLECTION bean, right?
OR
I would have ITEM's ejbCreate() method that would take the proper primary key like (ITEM_COLLECTION_ID,ITEM_ID)...
(I would go with this second option I think)
More questions will come out of me when I get into detailed relationships b/w the Entity beans...
Thanks ton for the help so far. Being alone in J2EE development is difficult you know.
Regards
Maulin

[David Harkness]

Originally posted by Maulin Vasavada:
Now, I have been generating the IDs for my record depending upon some logic so I guess that before calling create() I must get the new ID for the record and then call create() as otherwise create() can't magically know the ID of the record.

Actually, it can and must. While the *client* wanting to create a new entity bean calls create(...) on the bean's home interface, the container will call two special callback methods on the bean class: ejbCreate(...) and ejbPostCreate(...). Think of this as "INSERT INTO <bean> VALUES ( ... )" but broken into two steps. Note that the (...) denote the parameters for the methods and each create(...) must have a matching pair of ejbCreate(...) and ejbPostCreate(...) methods.
The first method, ejbCreate(...), should create the PK for the bean, set its primary attributes (those that uniquely define the entity), and return the PK. The second method, ejbPostCreate(...) is used to set any relationships -- things that require that the PK be set. You can define any number of create(...) methods (at least one obviously) using the standard Java overloading mechanism.
Any decent book on EJB will provide ample examples of this. The key to your question is that you'll generate the bean's ID/PK in its ejbCreate(...) method and return it. The container will associate it with the bean.

Originally posted by Maulin Vasavada:
I would create entity bean for ITEM within that ITEM_COLLECTION and in my case ITEM_COLLECTION would also be an entity bean. . . . In this case, I guess I would have creation of ITEM entity bean embedded in the ITEM_COLLECTION bean, right?

How you do this will be affected by whether or not you're using container-managed relationsips and the patterns you choose to follow. It's a good idea to have all access to your entity beans go through session beans. The session beans implement the business logic by working on the beans. Clients perform actions by going through the session beans. This way you won't be totally hosed when you decide to swap out entity beans for Hibernate or JDO. Again, pick up some books; they will help immensely.
If you use container-managed relationships, you don't deal so much with PKs and FKs. Instead you deal directly with the EJBObjects: addressBean.setUser(userBean) rather than addressBean.setUserId(userBean.getId()). You can also navigate the relationships in EJB-QL. Without CMR, it's much closer to working with a relational database (doing joins yourself).