> I can imagine NOT using entitybeans in the following cases:
>
>* When the data is read only data and/or need to get fast into the db
>(calling some sessionbean or inserting directly into the database)
By the way, does the entitybean container make any assumptions on what is in
the database, meaning: does it assume that all changes transit through the
entity container? If so, inserting directly into the database will burn and
go up in flames... If not, every update to the database will have to re-read
whatever is in the database, compare it to what is being changed, and only
then apply the changes or possibly resort to throwing exceptions ... Does
the transaction manager + CMP container do this?
>* When the client wants big resultsets to edit/display.
Does that really detract from using one entity bean per row? If lots of
users want big resultsets I guess you may need a big entity container (if
the resultset tend to require always different entitybeans). But then again,
by going directly to the database you will displace the problem to the
caching system of the rdbms, which is definitely much harder to tune, if it
can be tuned.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
