Sorry that I don't have the Qi4j sources in front of me right now, but;
Not sure I understand what you are saying, because there is a lot of
"HOW" but not much "WHY", which is what I am really looking for.
Nevertheless, I think what you are trying to describe is that Neo is
particularly suited to handle long-running conversations in
transaction scope, so that an entity representation built by Neo
within a Neo transaction should continue to live in that transaction
until the UoW completes, even if this takes hours. I.e. the Java
object that Neo pulls out of its hat is the underlying Java object of
a Property. Is this correctly understood?
I think that is one use-case you are fishing for.
The other use-case, which I personally have no clear picture of is
that two EntityStores are "bound" to the same UnitOfWork (is this
supported at the moment?), so that if NeoEntityStore creates a
transaction in prepare() there will be a conflict in the
LdapEntityStore if it also creates a transaction in the same thread. I
don't know JTA well enough to understand this issue.
Now, is the requirement what you describe, or is it that UnitOfWork
will need to integrate with a "TransactionManager" and the UoW does
the controller work needed?
If so, then the question becomes how to integrate these two (maybe
more) use-cases into a sweet SPI, which I suspect will be totally
separate from the EntityStore one.
Cheers
Niclas
On Mon, Jun 9, 2008 at 6:52 PM, Tobias Ivarsson
<[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
