On Mon, Jun 9, 2008 at 9:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> Tobias,
>
> I would like to know the use-case for the transactions before having
> an opinion about it.
>
> Are we talking about some outside application managing the transaction
> of which the EntityStore needs to be part of, or is it a Qi4j
> application that now needs transactions... I just simply don't see the
> use-case... Enlighten me with something real...
In this particular case I am (as you probably know) working with the
Neo4j EntityStore.
In Neo4j all actions that modify the node space must be enclosed in a
transaction. This is the case with many other persistence systems as
well.
I would say most persistence systems deal with transactions, or at
least all serious ones.
As you and I discussed in a previous thread, transactions are an old
and inflexible model, that we don't want in Qi4j.
In Qi4j we have the UnitOfWork. And, as is the case with transactions,
the (modified) state of a unit of work should either be persisted in
its entirety or none of it.
Until all code is written for Qi4j we will have to support using other
systems from Qi4j, such as persistence systems. Therefore we need to
provide an SPI that is flexible enough to support a wide variety of
persistence systems while fitting the Qi4j-model.
The current EntityStore SPI supports the working model where you copy
all relevant state from the persistence system to an in-memory
representation, make modifications to the in-memory representation,
then overwrite the persisted model with the state of the in-memory
representation, really well. But that might not be the best working
model for all persistence systems. It definitely isn't the "Neo-way".
The Neo-model is very close to the EntityState-model. The only
mismatch at the moment is this slight limitation in the EntityStore
SPI.
The most efficient way to work with Neo is to wrap the Neo-primitives
in domain objects (the EntityState objects are excellent for this),
and operate on the domain objects within a transaction. To be able to
do this, while not needing to bother the application level developer
with transactions management, we need to provide enough hooks for the
Neo EntityStore to be able to manage the transactions.
Currently the problem arises at the invocation of
EntityStore.prepare(...). Since we cannot know which UoW invoked the
method without examining the EntityState objects that were passed in
there is no good way of getting the transaction(s) associated with the
EntityStates that are to be persisted.
The changes I have suggested would make it a lot easier to manage such things.
I am not sure that my proposed changes are perfect, but I think they
are good enough to discuss. And this is that discussion.
I agree that for many persistence systems this will not be
interesting, but since Qi4j is such an awesome system, they don't have
to either. We could simply update them as follows:
Given a current implementation of EntityStore:
@Mixins( MyEntityStoreMixin.class )
interface MyEntityStoreService extends EntityStore, ServiceComposite {}
class MyEntityStoreMixin implements EntityStore {
// body
}
we would instead have:
@Mixins({ DefaultEntityStoreMixin.class,
IgnoreSuspendAndResumeMixin.class ,MyEntityStoreMixin.class })
interface MyEntityStoreService extends EntityStore, ServiceComposite {}
abstract class MyEntityStoreMixin implements EntitySession {
// Same body as above
}
Where DefaultEntityStoreMixin and IgnoreSuspendAndResumeMixin are
provided by Qi4j as follows:
class DefaultEntityStoreMixin implements EntityStore {
@This EntitySession session;
public EntitySession getSession() {
return session;
}
}
abstract class IgnoreSuspendAndResumeMixin implements EntitySession {
public void suspend() {}
public void resume() {}
}
Please, do comment!
--
Tobias Ivarsson <[EMAIL PROTECTED]>
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
