Entity Bean Pool

Question

Weblogic(6.1) deployment descriptor allows configuration of entity bean pool size
and cache size. Since calls from multiple clients to the same entity bean are
serialized what is the benefit of having multiple instances in an entity bean
pool?
Thanks,
Stefan

Answer 1

Anand,
Of course I don't talk about an extreme case of a table with one row!?, but the
same (logical) entity bean with same primary key accessed by multiple clients.
Each client will use findByPrimaryKey method and will get a reference to same
entity bean mapped to the same "row" in database . My surprise was that even for
this case there are multiple entity instances created in the pool for one row
in the database. For multiple instances mapped to multiple rows we concluded all
makes sense.
thanks again,
Stefan
"Anand Byrappagari" <[email protected]> wrote:
Stefan,
I am not sure I understand your question but if you are asking why
have
pooling, pool of instances is a feature for all types of entity beans.
In
the specific case that you have where the table has only one row it has
limited application but the general case is that you lave multiple rows
in a
table. For example, an Address table will in all probability have hundereds
of addresses of customers. An application accessing this table will be
accessing multiple address instances at any given time. So each of this
instances should be accessable independently hence the pool makes sense
in
this case. I point I am trying to make is that when you define a pool
for a
bean (AddressBean) you are not defining the pool for one instance of
the
bean type(like address_1). The pool specifies the number of instances
(address_1, address_2, ...., address_n) that can exist at any given time.
Are you asking if the pool size is for each row? That is if pool
size is
set to 10, are you asking if you can have atmost 10 instances of address_1
as opposed to 10 instances of any address? The pool and cache sizes refer
to
the limit on any instances and not on 1 instance.
Even in the extreme case like the one you mention where the table
has
only one row, there is some utility in having multiple instances as this
would not require serializing access to the bean - in exclusive strategy,
once a client has locked an EJB instance, other clients are blocked from
the
EJB's data even if they intend only to read the persistent fields. If
you
set the strategy to database then multiple instances can access the data
depending on the isolation levels you have set. Read Chapter 4 of
"Programming Weblogic Enterprise JavaBeans" for more information.
Hope this helps.
-- Anand
"Stefan" <[email protected]> wrote in message
news:[email protected]...
Anand,
If we established that same databse row can be mapped to multiple entitybeans
instances we are back to my original question: Assuming "database"concurrency
strategy, how do you see this model useful if calls from multiple clientsare
serialized across all these instances? I cannot point out the benefitof
the pool
of entity bean instances for same row since they all wait for a clientcall to
finish before replying to another client. Where is the benefit of havingmultiple
instances if one instance would do the same job?
thanks,
Stefan
"Anand Byrappagari" <[email protected]> wrote:
The default concurrency-strategy in weblogic 6.1 is database which
means
that concurrency is taken care of at the database, this model allows
you to
have multiple ejb object instances for the same row in the database.
If you
want a single instance then you can set <concurrency-strategy> element
in
the deployment descriptor for the ejb to Exclusive.
-- Anand
"Stefan" <[email protected]> wrote in message
news:[email protected]...
Thanks Anand,
Sure this way it makes total sense. However I used an example whereI was
referencing
only one row from multiple clients. For this case using the WeblogicConsole I
saw the number of bean instances growing. This would indicate thatsame
row is
mapped to multiple bean instances in the pool, which prompted my
question.
Stefan
"Anand Byrappagari" <[email protected]> wrote:
Think of entity beans as mapping to a row in a database. Access
to
a
single
row is synchronized not to all the rows. So it still makes sense
to
have
multiple instances possibly mapping to multiple rows in the database.
-- Anand
"stefan" <[email protected]> wrote in message
news:[email protected]...
Weblogic(6.1) deployment descriptor allows configuration of entitybean
pool size
and cache size. Since calls from multiple clients to the same
entity
bean
are
serialized what is the benefit of having multiple instances in
an
entity
bean
pool?
Thanks,
Stefan