El 17/05/2014, a las 14:41, Dan Haywood <d...@haywood-associates.co.uk>
escribió:
> On 15 May 2014 00:57, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>> Dan, please, correct me as needed :-))
>>
>> The commands are added to a queue, and that queue is emptied on each
>> transaction.
>>
>>
> correct
>
>
>> The point is that Isis, for example, generates a new transaction on each
>> action invokation.
>>
>>
> correct
>
>
>> In the context of tests, that could be simulated by wrapping the calls (it
>> would also force other business rules) to actions, and setters.
>>
>>
> sort-of.
>
> I've just been double checking as to the behaviour of transactions in
> tests; it is fairly sane, I think, though not well documented.
>
> We set up a new transaction for each test. The same transaction is present
> for the setup and the test method itself, in a state of IN_PROGRESS.
>
> You can confirm this using
> IsisContext.getTransactionManager().getTransaction().getState().
>
> IsisSystemForTest.get() is a thread-local representation of the running
> system. Using this, it is possible to commit/abort and begin new
> transactions at any time:
>
> * IsisSystem.get().commitTran()
> * IsisSystem.get().abortTran()
> * IsisSystem.get().beginTran()
>
>
> The interaction of transactions with/without wrap() is as follows:
>
> 1. if a transaction is in progress (the default), then invoking without
> wrapping (as expected) takes place in the context of that interaction; the
> transaction is not committed
> 1. if a transaction is in progress, then wrapping - at least as far as
> transactions are concerned - has no effect; the interaction is performed in
> the context of the current transaction
> 3. if a transaction has been explicitly committed (so that none is in
> progress), then invoking without wrapping will cause an exception to be
> thrown ("no xactn in progress")
> 4. if a transaction has been explicitly committed, then wrapping will
> automatically begin and commit the transaction around the interaction.
>
> So, Oscar, your statement corresponds to option 4, and is correct if the
> xactn had already been committed explicitly (in the setup, say)
I understand. That's the reason why sometimes
this.nextTransaction();
is mandatory on BDD steps...
It can be unnecessary if you do a getContainer.flush() on each persist if it's
needed mainly for sending changes to the database and for DataNucleus to
automatically manage bi-directional relationships.
>
>
>
>> In our case, we have created a persist method on each repository that
>> persists the domain object and also executes a flush.
>>
>>
> A reasonable pattern. I'm pretty sure that any repository query will
> always do a flush anyway (analogous to Hibernate auto-flush function).
So if this is the case, why not the default "persist()" implementation always
do a getContainer.flush() by default, in order to avoid confusions like this
one?
There can be an alternative "persistWithoutFlush()" method if required.
>
>
>
>> Perhaps its performance would not be as good for bulk inserts, but in the
>> context of our domain we prefer to force the flush on each persist than the
>> performance gained by queueing the database commands to be sent in blocks.
>>
>>
> If bulk inserts are ever required, then a good pattern is to define a
> domain service to do this sort of work. Then, start out with a naive
> implementation that just does individual flushes, and switch in a more
> performant implementation (eg calling stored procedures or whatever) if and
> when required. So long as the integration tests pass...
>
> On the topic of performance (for queries), do note that in 1.4.0 we
> introduced QueryResultsCache. And, DN has various L2 caching options for
> truly immutable data.
>
We have some derived properties in our domain that are quite intensive on its
computation. We are planning to use the cache method you implemented for
actions.
> Cheers
> Dan
>
>
>
>
>> HTH,
>>
>> Oscar
>>
>>
>>
>>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen
información reservada que no puede ser difundida. Si usted ha recibido este
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al
remitente mediante reenvío a su dirección electrónica; no deberá copiar el
mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un
fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener
el contacto con Ud. Si quiere saber de qué información disponemos de Ud.,
modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al
efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección:
Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y
Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su
responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan
virus informáticos, y en caso que los tuvieran eliminarlos.
