On Wed, 2006-03-08 at 23:24, Anil Gangolli wrote: > Allen Gilliland wrote: > > just a reminder, silence == consent. i am planning to move forward with > > development on this. > > > > -- Allen > > > I added some comments to the proposal page (Design Overview Section 2). > There are some considerations you really should take into account if you > move the transaction demarcation into the managers.
sorry, i didn't see that. > > I understand your goals, and I'd just urge taking a couple of > precautions. There are some dangerous curves on that road. You might > want to do the development in a branch and integrate back when you've > got the kinks out. You might also want to talk with some folks whose > knowledge of transaction management you trust. > > Finally, (though I know I'm unlikely to convince you), you might want to > consider an alternate strategy that removes explicit transaction > demarcation calls from the app layer, but rather than putting them into > the manager layer, puts them at a small number of well-defined points in > the request dispatch infrastructure (above/outside the app layer proper > rather than below it). I think this is closer to the existing Roller > design (before such calls proliferated into the present mess). I'm not sure exactly what points you are talking about. You mean like before/after a struts action? beginning/end of a request/response? The only reason I am reluctant to push this logic anywhere outside the persistence layer is because I find that in some cases I may want to do 2 or more transactions in a single request, but those transactions should be independent of each other. So I would need to know that transaction 1 had succeeded before deciding to do transaction 2. If the transaction demarcation was pushed somewhere outside my ability to notice it then my operations may not be wrapped in transactions the way I expect. > > Matt's suggestion of using Spring's declarative demarcation is another > good alternative. > > My number one suggestion is that no matter which way you go, pick one of > the known and commonly used patterns and adopt it, and depending on the > choice you may find existing infrastructure that supports it that you > can also adopt. I am actually of the belief that the pattern I suggested is commonly known and used. Maybe it's just me, but in all of my experience with apps of similar complexity to Roller I have never had the need to push transaction demarcation outside the persistence layer. Granted that, like Roller, the persistence layer is more generalized type Manager layer. As I said in my proposal I believe that increases complexity and introduces a potential for problems if someone accidentally (or purposely) doesn't include the correct transaction demarcation methods around their code. I think I could reasonably argue that is the case with the Roller codebase right now. The methods are there, but they are not fully implemented, which is confusing. -- Allen > > --a. > > > > > > > On Mon, 2006-03-06 at 13:25, Allen Gilliland wrote: > > > >> Okay, here is a more flushed out proposal of what I think should be done > >> ... > >> > >> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_BackendRefactorings > >> > >> Note that the driving force behind these changes is to 1) prevent direct > >> access to the PersistenceStrategy from outside the business layer and 2) > >> limit persistence logic (like transaction details) to the business layer. > >> > >> I think those are very appropriate goals to have for the architecture of > >> our code. > >> > >> -- Allen > >> > >>
