>From a user's perspective.... I like the lookup(String name) and I agree with Berin that
lookup(ConnectionManager.ROLE, "SSL"); is 'cleaner' than lookup(ConnectionManger.ROLE + "/SSL"); It might also be nice to have some Query like object in the future and/or in more advanced containers. As for Transactions, when I was teaching EJB courses, people had a hard time with transactions and I would agree that one should really evaluate if they are needed. If so, you might as well use EJB as that is what their containers are designed for (among other things of course). I guess it goes back to keeping it as simple as possible while still having some flexibility. - Robert -----Original Message----- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 7:47 PM To: Avalon Developers List Subject: Component Transactions Hi, Glad to see that Berin has finally come over to the dark side ;) Two points to make (they may be familiar to you); Object Role? ------------------- Why do we need Object passed in as Role key? Why couldn't we have a String passed in. And if we were going to pass in a string then why don't we concaternate the strings on clientside and have a simple interface such as public interface ServiceManager { void lookup(String name) throws ComponentException; boolean exists( String name ); } Note that I kept the ComponentException as it should only be raised in error condition. Comonent "Transactions" ------------------------------------- Several people have pointed that you will need to have what I am terming "component transactions". ie You may have a top-level method M1 the calls a worker method M2. However M2 may access resources R1, R2 & R3 that should be released at the completion of M2. M1 may access R1, R2 & R3 later and we want them to be available when M1 tries to access them. This is what I will try to address here. In the simple case (like in Phoenix) you can have container manage the Component resources and release when necessary and invalidate stale references (so that calls to stale objects raise InvalidStateExceptions). In this case the transaction lifecycle looks like Transaction tied to lifecycle: -------------------------------------------- Transaction.begin() - startup component - run component - shutdown component Transaction.end(); -------------------------------------------- If we assume that all Cocoon components can not create threads in their requests and that there is no nested-transactions then the following could work Transaction tied to thread: -------------------------------------------- - startup component For each request; Transaction.begin() - request() Transaction.end(); - shutdown component -------------------------------------------- The complexity starts when you need to create a transaction inside another transaction. ie You want to call M2 from M1. If you are familiar with EJBs then you will recognize that this is where you would declare transaction capabilities like NONE, REQUIRE_NEW, REQUIRED, SUPPORTS (and about 5 other attributes that I can never remember). If you really need this capability (and I would encourage you to profile before assuming you do) then I would encourage you to look at existing Java Transaction API and see if you can get it to do your work. Rollback/completion would for our purposes means same thing (ie release aquired resources). You could even do insane things like generate proxies that already supports EJB-like transaction attributes. However if you are doing this sort of thing it really sounds like you are mixing tiers and you should really consider moving you buisness logic to another Container (be that EJB, Phoenix or something that just sits side-by-side to Cocoon). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
