> 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...
I believe the ejb model does not care if you insert the data from a non ejb
client.
After checking the spec. i read:
------------------------------
9.1.10 Commit options
The Entity Bean protocol is designed to give the Container the flexibility
to select the disposition of the instance state at transaction commit time.
This flexibility allows the Container to optimally manage the caching of
entity object�s state and the association of an entity object identity with
the enterprise bean instances.
The Container can select from the following commit-time options:
� Option A: The Container caches a �ready� instance between transactions.
The Container
ensures that the instance has exclusive access to the state of the object in
the persistent storage. Therefore, the Container does not have to
synchronize the instance�s state from the persistent storage at the
beginning of the next transaction.
� Option B: The Container caches a �ready� instance between transactions. In
contrast to Option A, in this option the Container does not ensure that the
instance has exclusive access to the state of the object in the persistent
storage. Therefore, the Container must synchronize the instance�s state from
the persistent storage at the beginning of the next transaction.
� Option C: The Container does not cache a �ready� instance between
transactions. The Con-tainer returns the instance to the pool of available
instances after a transaction has completed.
---------------------
I guess option A is the answer to your question. If a non-ejb client tries
to access a bean in a transaction it will not be allowed to by the database.
> >* 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.
I guess you need a kind of understanding of load and connections to
determine the size of the returning resultsets.
/Jon
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
