At 11:11 11.04.00 , Jens Stutte wrote:
>Hi,
>
>this i did not know. So, the EJB spec wants to ensure that even if the
>database is changed from outside the EJB server, that the beans are up to
>date ? Well, it's a very nice Feature in some circumstances - but in some
>circumstances (if i am sure, that nobody from outside will ever change the
>DB) it is a great slow down. I always thought of the EJB Server as a kind of
>cache between the client and the database (ok, not only a cache...). Even if
a common misconception. most important thing of the entity bean component
contract is the integrity of the data. "abusing" entity beans as a cache is
an option a conatiner vendor may or may not give you but for that (as you
noted) it has to be sure it's in complete control of the persistent storage.
>the spec requires this behaviour, what about an additional configuration
>option for an entitre application (or even for each bean ?) to tell the EJB
>server that he is the only one to access the DB and therefore can ommit a
>lot of calls to ejbLoad (that ejbStore is neccessary after each transaction
>is clear, in this case the bean must decide, if it's been changed).
>
>Just a wish...
it's already there:
<!ELEMENT entity-deployment (primkey-mapping?, cmp-field-mapping*,
finder-method*, ejb-ref-mapping*, resource-ref-mapping*)>
<!ATTLIST entity-deployment call-timeout CDATA #IMPLIED
data-source CDATA #IMPLIED
exclusive-write-access CDATA #IMPLIED
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
isolation CDATA #IMPLIED
location CDATA #IMPLIED
max-tx-retries CDATA #IMPLIED
name CDATA #IMPLIED
table CDATA #IMPLIED
validity-timeout CDATA #IMPLIED
wrapper CDATA #IMPLIED
>
>Jens Stutte
>
regards,
robert
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
