>1. If two clients both use primary key to find an Entity bean, how >does
the container know that there is already a bean in existence for >the second
caller, especially if the second caller sues a different >primary key that
resolves to the same row from a relational table or >object from an OODBMS?
There probably won't be any beans created by finder method.
The container will most likely create the proxy object and
associate it with the returned PK (from a bean instance).
If you call the finder with the same PK, then the container will
detect there is already a proxy object with that PK and does not
create another one.
Note the distinction between the bean and its proxy(what the client sees).
The bean needs only to exist for the duration of a transaction.
BTW two different PK's identifying the same row doesn't make sense.
>2. You apparently can code find methods that return groups of primary
keys, like an Enumeration. Does this mean that the container will create >a
set of entity beans and return keys or handles for all those beans?
Yes.
>I'm asking about his because I thought that a single entity bean mapped >to
a single row, so this kind of finder method is quite different from
>findByPrimaryKey. I realize there are times you might want to get back
>multiple rows/multiple beans, so I assume this is the way to do that, >but
I wanted to check.
If you don't want multiple EJB objects returned, use a session bean.
>3. Given the overhead of creating entity beans, if you needed to do a
>select with a potentially large result, can you simply have a session >bean
do a query and get back a normal result set without using entity >beans at
all? I assumethat's the case, but I wanted to verify it.
You should use a session bean.
>4. Transactions, commit and entity beans.
>Here's an example scenario: I have an entity bean that represents, >let's
say, an airline reservation. SO the caller invokes:
> setPassengerName()
> setSeatAssignment()
> setBadAirlineFOodPreference() (there may be e an airline with good
>food, but United, SUn's primary airline, isn't it).
> swtFrequentFlyerNumber()
>Each of those is a method. As I understand it the container is required
>to start a transaction when any of the methods of an entity bean is >called
and complete that transaction when the method ends (logically >enclose the
method in a begin()...commit() wrapper so to speak). In >that case, the
container is doing an awful lot of database calls, >because it must do a
commit for every little
>change to the data in the bean. If this isn't what happens, how does
>the container decide when to do a commit, since there's no method, so >far
as I know,to say to the bean, "I'm all done so you can commit now)" >How
does the container decide this?
If the container started the transaction (based on method transaction
attribute set in your DD), then it will complete it when your method
returns and you are right it doesn't know (or care) what has changed.
>4. How can I make the data a bean represents read-only? Do I have to >go
tothe database engine itself and make the table read-only? Thanks.
>Since all data manipulations are done in the entity
Entity beans represent for transaction oriented business objects, if
your needs are read only, I would use session beans and simple data
objects.
>Ken
Hamid
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
