You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/06/07 02:46:44 UTC
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component Transactions
Posted by Robert <rm...@bull-enterprises.com>.
>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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Component Transactions
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> 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 );
> }
I never said a Role should be an Object, but that we should have a
method for a String role and an Object hint for more complex queries.
That way we don't have to have MyCOmponent.ROLE + "/specific", we
keep the separate parts separate.
>
> Note that I kept the ComponentException as it should only be
> raised in
> error condition.
Yeah, but it needs to be tested for. If the only thing that can
go wrong on a *lookup* is that a component is not there, we should
make that exception a RuntimeException. That way components who
assume everything to be OK (the usual case) don't have to do more
work than is necessary. Others that want to catch the RuntimeException
can still do it.
This is done not by explicitly declaring the exception in the
interface, but in its javadocs:
public interface ServiceManager
{
/** throws ComponentException if component is not available */
Object lookup(String role);
/** throws ComponentException if component is not available */
Object lookup(String role, Object hint);
boolean exists( String name ); // do we need more specific version?
}
<snip/>
I will look at the rest of the message in detail
offline.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>