avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert" <rmcint...@bull-enterprises.com>
Subject RE: Component Transactions
Date Fri, 05 Jul 2002 18:31:38 GMT
>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:peter@apache.org] 
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message