At 14:08 21.07.00 , David Sierra Fernandez wrote:
>I could assure you that in ATM example, if you make a "commit" every time
>you create or destroy a row in the database through SQL (ORACLE) the
>Automatic Teller MAchine will detect all the changes.
>
>I don't know why but this is the way it is.
of course, because by default orion adheres to the spec and at the
beginning of each transaction reloads the entities' state from the db,
which you changed and committed in an earlier transaction. did I say
anything that contradicts that?
regards,
robert
>More opinions ???
>
> -------------------------------------------------------------
> David Sierra Fern ndez
> Ingeniero Tecnico de Telecomunicaci¢n
> AULA RETECAL (CEDETEL) Universidad de Valladolid
> Campus Miguel Delibes E-Mail: [EMAIL PROTECTED]
> 47011 Valladolid (SPAIN)
> --------------------------------------------------------------
>
> -- Sierr@ --
>
>On Fri, 21 Jul 2000, Robert Krueger wrote:
>
> >
> > this is incorrect. the container has to ensure that when a transaction is
> > started the entity beans involced in that transaction have to be in sync
> > with the underlying datastore. depending on your transaction isolation
> > level this locks the record associated with your entity in the db during
> > the transaction. if you modify the record with another client, the next
> > transaction that is started and involves that entity should reload the
> > current state, otherwise the container doesn't conform to the spec. so if
> > you deleted records, the load operation should throw an exception.
> however,
> > most containers (including orion) allow you to specify a flag that
> > indicates that your server is the only thing writing to the database to
> > avoid the expensive load operations at the beginning of each transaction.
> > if you specify that and still modify the database from outside, you're on
> > your own and can no longer rely on the spec. the effect that you cannot
> > recreate an entity that you deleted manually looks like it's a caching
> > problem (somewhere there's a hashtable of primary keys kept in memory
> > that's not updated when the database record is deleted manually). so if
> you
> > use the exclusive-write-access option then you're to blame. if you
> don't, I
> > guess orion shouldn't behave that way and you should probably consider
> it a
> > bug and post it to [EMAIL PROTECTED] but I might be wrong.
> >
> > regards,
> >
> > robert
> >
> >
> > At 14:48 20.07.00 , Nick Newman wrote:
> > >Hi Rick,
> > >
> > >The EJB spec says that once the entity bean is loaded from the database,
> > >the container (Orion) doesn't have any responsibility to keep track of any
> > >possible changes to the database. So what you are doing is basically
> > >sneaking behind Orion's back.
> > >
> > >The consequences of this depend on the circumstances, I
> believe. Here's my
> > >best guess ...
> > >
> > >Suppose the server had not been busy for quite a while. Under these
> > >conditions Orion would have written all its entity beans back to the
> DB and
> > >removed them from memory. If you now empty the DB, then all the entity
> > >beans are gone (in the sense that trying to find one from its primary key
> > >will fail).
> > >
> > >If the server is extremely busy when you emtied the DB, then all the
> entity
> > >beans may well have been in memory, and they will get recreated in the DB
> > >when Orion writes them out.
> > >
> > >Hope that helps.
> > >
> > >Nick Newman, SCIENTECH
> >
> > (-) 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
> >
> >
> >
(-) 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
