Entity Bean -- Few questions

[rajesh.shiggaon]

Hi Everyone:

I have some questions on the entity beans, these have been bugging me
for a quite time. So just thought of getting them straight.

1) The primary key object thats gets generated after the create/finder
methods from the EJBHome interface, how is that related with EJBObject?
a) How the container relates this Primary object with EJBObject? I know
that Container keeps track of this primary object.
b) Lets say an Entity bean EJBObject has been created for a particular
record. If a new client wants to access the same record a weather a new
EJBObject gets created or the same one will be used? Will there be
different Primary object instance also or only one?

2) If you could see the "Client View of Entity Object Life Cycle" in
the EJB spceification, they say that whenever we directly delete a
record from a DB, how does the EJBObject also gets deleted with it?
a) Does the container always keep on querying on the DB and then delete
the EJBObject?
b) If it does not what is the use of the callback method of ejbLoad().
If it could not find the record based on the primary key that it gets,
then how it should handle? it cant even written back an expection
saying that the record doesnt exist

If any of the questions are misleading or not understandable, let me
know I can reframe those.

Thanks in advance

Rajesh Shiggaon

 

[David Linsin]

Hey there,

I think almost all the answers to your questions are hidden somewhere
deep down inside the container implementation. I don't know, but I
think your questions are almost very container specific. Which
application server are you using?

Greez, David

 

[rajesh.shiggaon]

I am usuing the WebSphere. But I feel all the questions are not related
with a specific application server.

 

[Doug Pardee]

1) The primary key object thats gets generated after the

create/finder methods from the EJBHome interface,
how is that related with EJBObject?

The container will locate or create an Entity bean with that primary
key.

a) How the container relates this Primary object with EJBObject?
I know that Container keeps track of this primary object.

The container will obtain an appropriate unused Entity bean, either
from its cache or by creating it. It will then configure that bean for
the primary key by calling setEntityContext().

If the Entity bean uses Commit Option C or is defined as a read-only
EJB (container-specific extension), the container probably will attempt
to reuse the specific Entity bean instance that was last associated
with that primary key.

b) Lets say an Entity bean EJBObject has been created for a
particular record. If a new client wants to access the same
record a weather a new EJBObject gets created or the same
one will be used? Will there be different Primary object instance
also or only one?

There is never more than one instance of an Entity bean with a
particular Primary Key value. The new client will get the same
EJBObject. If that EJBObject is currently in use by another client, the
new client will be forced to wait until the EJBObject is no longer in
use.

2) If you could see the "Client View of Entity Object Life Cycle"
in the EJB spceification, they say that whenever we directly
delete a record from a DB, how does the EJBObject also gets
deleted with it?

It doesn't.

a) Does the container always keep on querying on the DB
and then delete the EJBObject?

No.

You cannot "directly delete" a record from the database while the
record is involved in a transaction. Whenever the Entity bean is
associated with the record, it has to be part of a transaction. Thus
you cannot "directly delete" a record from the database while there is
an Entity bean associated with that record.

Once the transaction is complete (committed or rolled back), the Entity
bean is no longer associated with that database record.

The next time that an Entity bean is to be associated with a database
record, "ejbFindByPrimaryKey()" will be called for the very purpose of
looking in the database to see if the record still exists. This will be
called as part of the new transaction.

If the Entity bean uses Commit Option C or is defined as a read-only
EJB (container-specific extension), you must not "directly delete" or
otherwise alter the database record at all.

b) If it does not what is the use of the callback method of
ejbLoad(). If it could not find the record based on the primary
key that it gets, then how it should handle? it cant even
written back an expection saying that the record doesnt exist

This should never happen in ejbLoad(). ejbLoad will not be called
unless ejbFindByPrimaryKey says that the record exists, and both calls
occur within a single transaction so the record is locked between the
calls.

The use of ejbLoad() is quite simply to access the database record and
to load the record information into the EJB. It will be called at the
beginning of every transaction, unless the Entity bean uses Commit
Option C or is defined as a read-only EJB (container-specific
extension).

 

[rajesh.shiggaon]

The container will locate or create an Entity bean with that primary
key.


The container will obtain an appropriate unused Entity bean, either
from its cache or by creating it. It will then configure that bean for
the primary key by calling setEntityContext().

If the Entity bean uses Commit Option C or is defined as a read-only
EJB (container-specific extension), the container probably will attempt
to reuse the specific Entity bean instance that was last associated
with that primary key.


There is never more than one instance of an Entity bean with a
particular Primary Key value. The new client will get the same
EJBObject. If that EJBObject is currently in use by another client, the
new client will be forced to wait until the EJBObject is no longer in
use.

Several Entity bean instances may represent the same underlying Data.
But every Enterprise bean will be run in a single thread... they are by
default thread safe. I am not sure about the instances of EJBObject and
primary key objects. Can there be several instances of the same primary
key value?

For every client who wants to use the Enity bean for the same record
will have the same EJBObject?

It doesn't.

It does --- version 2.1 EJB specification, page no 134

No.

You cannot "directly delete" a record from the database while the
record is involved in a transaction. Whenever the Entity bean is
associated with the record, it has to be part of a transaction. Thus
you cannot "directly delete" a record from the database while there is
an Entity bean associated with that record.

If we use the Entity bean in no transaction mode then how this will
work?

Once the transaction is complete (committed or rolled back), the Entity
bean is no longer associated with that database record.

The next time that an Entity bean is to be associated with a database
record, "ejbFindByPrimaryKey()" will be called for the very purpose of
looking in the database to see if the record still exists. This will be
called as part of the new transaction.

If the Entity bean uses Commit Option C or is defined as a read-only
EJB (container-specific extension), you must not "directly delete" or
otherwise alter the database record at all.


This should never happen in ejbLoad(). ejbLoad will not be called
unless ejbFindByPrimaryKey says that the record exists, and both calls
occur within a single transaction so the record is locked between the
calls.

Then ejbLoad() can throw NoSuchEntityException, how is this possible?
IF we use the attribute No transaction then how this will work for the
delete?

 

[Doug Pardee]

First, I need to correct a mistake that I made in my earlier posting.
When I wrote "Commit Option C", I meant "Commit Option A". That's what
I get for going back and adding a detail at the last minute, then
copying and pasting it

Several Entity bean instances may represent the same underlying Data.

Although it's possible for the container to implement Entity beans that
way, it generally just complicates things because all but one of the
instances would be blocked anyway. It also precludes the use of Commit
Option A (I got it right that time!). It's a lot easier for the
container to track a single instance of an Entity bean with a
particular Primary Key, and that's what the containers that I'm
familiar with all do.

If the container supports optimistic locking and the Entity bean is
designed and coded for optimistic locking, then of course there need to
be multiple instances. But in that case the Entity bean is specially
coded (as is the bean's caller).

It does --- version 2.1 EJB specification, page no 134

I think that you misunderstand that paragraph. That paragraph is in a
section that starts, "This section describes the life cycle of an
entity object from the perspective of a CLIENT." (emphasis added) It is
not from the perspective of the bean, the bean provider (you) or the
container.

That paragraph simply acknowledges that other clients may be adding and
deleting rows, and that rows can also be added and deleted via direct
database access. The paragraph reminds us that if the client hangs onto
an Entity bean reference (pointer) outside of a transaction, the
underlying data might be deleted and then the next time that the client
attempts to use the Entity bean it will receive a NoSuchObjectException
or NoSuchObjectLocalException (as appropriate) from the container.

If we use the Entity bean in no transaction mode then how this will

work?

Entity beans are intended to be used inside of transactions. If used
outside of transactions, they can exhibit psychotic behavior.

As you read through the Entity beans specification, you will see many
references to the "transaction context" that the bean is operating in.

Without an active transaction, the container might not call ejbLoad()
or ejbStore() at the appropriate times. In particular, the call to
ejbStore() is triggered by the committing of the transaction that
ejbLoad() was executed under. In the absence of transactions,
ejbStore() is only called just prior to ejbPassivate(). See, for
example, section 12.1.7.1 of the EJB 2.1 specification.

Without an active transaction, there is no isolation between clients of
the Entity bean.

Read-only beans (if supported by your container) are the only ones that
can reliably function outside of a transaction.

Then ejbLoad() can throw NoSuchEntityException, how is this possible?

Yes, ejbLoad() can throw NoSuchEntityException. See section 18.2.2.1 of
the EJB 2.1 specification.

But normally it doesn't need to. ejbLoad() is called in the same
transaction that the business method is being called in, which should
be the same transaction that ejbFindByPrimaryKey() was called in. Which
means that nobody else can have deleted the record.

IF we use the attribute No transaction then how this will work for the delete?

If you do that, you're on your own. As noted above, Entity beans other
than read-only beans should always be invoked inside of transactions.

If you set up your transactions properly, it all works very easily.