On Mon, Jun 9, 2008 at 2:25 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > 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,
No, not yet. We are experimenting with some ideas on how to better support long-running transactions. What I am saying is that Neo is particularly suited at handling conversations with only a thin layer of abstraction. > 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. That would probably be the best way to do it, even if the long-running transaction problem has not been completely solved in Neo yet. > I.e. the Java object that Neo pulls out of its hat is the underlying Java > object of > a Property. Is this correctly understood? More or less. It's true for primitive property values. And very close to the truth for serializable property values. What is more interesting is that associations between entities are modeled as relations between nodes in Neo. > 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?), I think it's supported, judging by the looks of the code, but I'm not sure on how it works. Specifically I am not sure on how the UnitOfWork know which EntityStore to query for a given QualifiedIdentity. > 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. If they have separate transaction managers I don't think there is any problem. Otherwise I don't know. It would work from the Neo side of things, but I don't know about the Ldap implementations. > > 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? That could be a solution, and perhaps a very good solution. The only case when this would not be optimal is if different EntityStore implementations work better with transactions being managed in some different way. For some stores the model where data is first fetched then modified and finally stored back is the best way to operate. In that case the interaction cycle consists of several transactions. At least an initial "read transaction" and a final "write transaction". > > 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. That sounds reasonable, although given the premises above, it would still be tightly coupled to the EntityStore SPI. -- 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
