"Kenneth D. Litwak" wrote:
>
> I've got some Entity bean questions, the answers to which I realize may be
> vendor-dependent, but maybe the spec says something I've missed.
>
> 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?
Most probably pk1.equals( pk2 )
Primary keys have to have the same value to be equal, but not
necessarily the same object.
> 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? 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.
findByPK returns the entity bean using the primary key. Other finders
returns the primary key which can then be used with findByPK to return
the entity bean. It's not mandatory and not something CMP would do, but
the EJB specs allows it to work like that.
> 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 assume
> that's the case, but I wanted to verify it.
Yes.
> 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?
You avoid this overhead by starting a transaction, performing several
updates to the beans, and then closing the transaction. You can do that
either from a session bean running in container-managed transaction, or
with client-managed transaction.
> 4. How can I make the data a bean represents read-only? Do I have to go to
> the database engine itself and make the table read-only? Thanks.
If you are using a good server, you can eliminate all set methods and
only support get methods. If a method does not change the contents of
the bean, the server should detect that and not perform any database
I/O. In an even better server you might specify read-only access to the
database.
arkin
>
> Ken
>
> ===========================================================================
> 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".
===========================================================================
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".
