On Wed, Sep 24, 2008 at 11:54 PM, Michael Hunger <[EMAIL PROTECTED]> wrote: > When looking at imdb examples the nodes are hold as delegates of the domain > objects. > > What is the implication of holding neo nodes from one transaction to another? > And whats the best patterns related to that.
I think the behavior will be exactly as you expect it would be, if you in your mind imagine that the entire node space is kept in an in-RAM structure. Except your RAM is transactionally safe and persistent. I say that "I think the behavior will be as you expect," because it may be that my expectations have shifted after having worked with Neo for a while. In the (unfinished) Guidelines for Building a Neo App, I talk a bit about that mindset: http://wiki.neo4j.org/content/Guidelines_for_Building_a_Neo_App#Mindset (Needs to be expanded, I know.) Basically, since all stateful operations are delegated to the underlying node (rather than mutating instance variables that at some later stage will be serialized to e.g. SQL), you in essence get transactional memory for free. This gives you neat features like rollback of your domain objects as well as improves parallelism without incurring any new concepts on the developer. > > The same question goes along regarding what are the best strategies of making > start nodes for traversal easily > accessible? By adding them directly to the reference node? By what > relationship do you do this normally. We typically use a subreference pattern, where the neoService.getReferenceNode() in turn ties in a few (typically <10) subreference nodes. Subreferences are mentioned in the outdated Design Guide: http://wiki.neo4j.org/content/Design_Guide#Subreferences Have a peek at the convenience neoUtil.getOrCreateSubReferenceNode() for an implementation: https://trac.neo4j.org/browser/components/neo-utils/trunk/src/main/java/org/neo4j/util/NeoUtil.java#L397 I like a naming convention on the relationship type to be something like REF_TO_USERS_SUBREF or USERS_REF_TO_SUBREF. But I tend to like more verbose and descriptive names than many others. > > On single method transactions like in neo-utils. It is sensible to support > that as this is certainly degrading > performance? And if so, wouldn't it be better to have neoservice support it > itself (when methods called without tx > thant create one for just this method). This could be done by having a > factory creating neoservices (and not calling > "new EmbeddedNeo" which I personally dislike. Adding an option to a factory > method for creating a decorator around the > neoservice that automatically starts transactions if there is none running > for the single method and finishes them > afterwards would be simple. I agree that that is a better solution than reimplementing specific methods in neo-utils. But the important question, as you point out, is whether this is a good idea. We debated quite heavily whether we should have Neo automagically open up a transaction if someone executed an operation without a transactional context. I was originally for, because of developer convenience, but at the end we opted not to. Today, I feel that that was the right decision: it does have the drawback of forcing the programmer to deal with transactions. OTOH, grouping logical business operations into a single cohesive all-or-nothing unit typically improves the domain layer code, and it also fixes the potentially gigantic performance hole that results from running every operation in a separate small transaction. Cheers, -- Emil Eifrém, CEO [EMAIL PROTECTED] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
