> I think pipelines are great, but I disagree with your example. Transaction
> handling depends on strategies like:
>
> - Requires
> - Requires New
> - Supports
> - Not Support
> - Never
>
> Each one should know how to begin/rollback/commit based on its type. Also,
> nested transactions should be considered. Then break down transaction
> handling in different pipelines sounds bad to me.
Ok even though I can nest transactions. This is how one triggers failure in
a series of triggers will roll back all effects. Perhaps my implementation
is a little more involved with the JNDI aspects I deal with. Anyway I don't
implement transactions or anything but saw that it can be in this fashion.
You can still give the strategies listed above life through such an
implementation.
>
> Right now I have some code that handles a 'Requires Transaction' mode:
>
>
> public Object invoke(Object target, MethodMetadata metadata, Method
> method, Object[] args)
> throws Throwable
> {
> boolean weAreTransactionRoot = false;
>
> Current cur = Current.getCurrent();
>
> if (cur.getTransaction() == null)
> {
> weAreTransactionRoot = true;
>
> cur.begin();
> }
>
> Object ret = null;
>
> try
> {
> ret = method.invoke(target, args); // Real method invocation
> }
> catch(Exception e)
> {
> // Failed
>
> if (weAreTransactionRoot)
> {
> cur.rollback();
> }
>
> throw e;
> }
>
> // Succeeded
>
> if (weAreTransactionRoot)
> {
> cur.commit();
> }
>
> return ret;
> }
>
>
> Hence, an execution pipeline that fits my needs would need a reference to
> the next entry in the chain:
>
> try
> {
> ret = nextInChain.invoke(target, args); // Delegation to the
> next one
> }
> catch(Exception e)
> {
> ...
>
> The last one in the calling chain should be the one that would really
> invoke
> the method.
>
>
>
Little different then what I have done but I can see where you're going.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
