Hi, It seems clear from a number of people's comments that the transactional facilities need to be more central to P5EE. (Obviously, the projects I have been working on recently haven't required them, so I have somewhat neglected them in P5EEx::Blue.)
I will be downloading bOP and evaluating making P5EE work with it. Rob: Does this seem like a good idea, and would you and bivio Software Artisans, Inc. look kindly on such a development? (Presumably this code base is actively developed, with lots of vision and direction for where it is going in the future.) Are there other mature transaction processing packages for Perl that I should be evaluating? Stephen At 01:02 PM 5/15/2002 -0600, Rob Nagler wrote: >[EMAIL PROTECTED] writes: >> Although I disagree on sessions vehemently. How are you >> to evolve to a 2-phase commit without them? > >Any transaction monitor need resource registration and transaction >creation facilitities. This is quite different from the concept of >P5EE sessions, which is a stateful bit bucket which resides outside a >particular transaction resource. > >P5EE should initially rely on the database's transaction monitor and >expand as the problem space requires it. In bOP, we have a simple >mechanism to register transaction resources with a request object, >which for now, does not implement two phase commit. It is sufficient, >because transactions aren't distributed. However we do need to be >able to rollback pending e-mail messages, locks, and other ephemeral >request resources should the request fail. > >Rob
