I understand but imaging this case... Model - Person encapsulates underlying node that access name property Controller - Handler that receives http request requests a model has transaction and delegates the model to a template to be rendered View - Template that gets rendered with domain objects
If a property accessed in the view from a domain object delegates the access to the value to a delegate node wrapped in the model it would be outside a transaction thus failing if it required one. If you have a view object that gets fully initialized from a domain object before passing to the view then it works but requires a extra layer of view objects and forces initialization of properties that might not ever be used in the rendering phase. 2010/1/12 Ryan Levering <[email protected]>: > Then this wouldn't be M-V-C, it would be M/C-V. The point of having > that separate layer is that you don't need to worry about the model > abstraction. Generally, controller level transactions should only > exist because you actually want to force multi-operation atomicity, > not because you know the underlying database needs to be > transactionalized. And again, if your controller is doing a lot of > reading, it will have to be split up into multiple transaction blocks. > > Ryan > > On Jan 12, 2010, at 5:28 AM, Mattias Persson wrote: > >> Your code doesn't need to be littered with transaction management. You >> can have a very big MVC (Model-View-Controller) application or >> something like that and _only_ have transaction handling in one >> place... in the Controller. >> >> See http://wiki.neo4j.org/content/Transactions#Best_practices (page >> under construction) >> >> 2010/1/12 Laurent Laborde <[email protected]>: >>> On Tue, Jan 12, 2010 at 6:41 AM, Ryan Levering >>> <[email protected]> wrote: >>>> >>>> 1. User.getName() >>>> >>>> I want a property off the node. I assume I encapsulate the single >>>> internal getProperty call in a transaction? My accessor code has >>>> just >>>> quadrupled in size, even if I am ok with this silly, time-consuming >>>> transaction. Leaving it out means every piece of code in my system >>>> has to understand to start a neo4j transaction just to get the >>>> user's >>>> name. >>>> >>>> 2: for (User user : getUsers()) >>>> >>>> I want to do something to all the users in the system. There are A >>>> LOT of them and they are all linked to a UserFactory or whatever. I >>>> can't create an internal list, because they won't all fit in memory. >>>> So I wrap the Iterable<Relationship/Node> in an Iterable that wraps >>>> the nodes in POJOs. Only there is no way to do this without >>>> enclosing >>>> that loop in a transaction. >>> >>> Ha ! Thank you for explaining my problem and POV in a much more >>> readable english than me :) >>> >>>> Do people just create giant transactions that wrap their entire >>>> programs since they don't work with large graphs/models? Or is your >>>> code entirely littered with transaction = service.beginTx(); >>>> transaction.success(); transaction.finish()? >>> >>> When i can, i have short transaction everywhere. >>> When i have a very big traverser to do ... well... i have a top-level >>> transaction. >>> Another workaround i use is to fill an array with the traverser, >>> and i >>> work on the array. >>> That why i switched to 8GB on my desktop PC -_-' >>> >>>> I've looked around on the wiki and site and I can't find good >>>> answers >>>> to these questions. The IMDB example transactionalizes things at a >>>> very high level. In a sense, wrapping the entire program (web >>>> request) in a single transaction. I guess that's fine if you have >>>> small operations and use Spring injection, but what if you don't? >>> >>> You do it the Oracle(tm) way : buy more ram :) >>> >>> -- >>> Laurent "ker2x" Laborde >>> Sysadmin & DBA at http://www.over-blog.com/ >>> _______________________________________________ >>> Neo mailing list >>> [email protected] >>> https://lists.neo4j.org/mailman/listinfo/user >>> >> >> >> >> -- >> Mattias Persson, [[email protected]] >> Neo Technology, www.neotechnology.com >> _______________________________________________ >> Neo mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Raul Raja _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
