Re: [JBoss-dev] TxInterceptor split is really really bad

Dain Sundstrom Fri, 21 Feb 2003 18:40:37 -0800

Jeff,

Don't let these guys push you around. Bill's just in a pissy mood today.

-dain

On Friday, February 21, 2003, at 06:01 PM, Jeff Haynie wrote:

Oh, I buy into it  - and I'm neither for OR against what David is
saying. I'm merely saying you should separate the concerns - but it
seems like that is obvious and redudant (although not so apparent with
all the back in forth) to you.
As you know, I don't work for Jboss Group. I'm just merely trying to
help out on my own *free time* and try and help make this a better
product with what little value I can add.
Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on.

Jeff
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jeff Haynie
Sent: Friday, February 21, 2003 6:15 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
Yes - but you guys don't seem to buy into it otherwise you won't be
talking about where and how tx or remoting should go into AOP.
Maybe I'm missing something.
I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D.

Bill
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bill Burke
Sent: Friday, February 21, 2003 6:09 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
I personally don't think AOP should have anything related to
transactions, remoting, etc. I think that should be pushed up into
the
functional areas that apply those specific semantics to the
subsystems
since they are quite different depending on the subsystem (JMS, EJB,
etc) and location (local,remote).
Where have you been?  Marc has been talking about creating an AOP
framework and services on top of this framework since the fall.  The
whole point is to break ourselves away from EJB and isolate and
abstract out distribution infrastructure even more from a coding
perspective.
Bill
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Hiram Chirino
Sent: Friday, February 21, 2003 5:17 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
I have to disagree.  Take a higher level look at the
basics: All client proxies have a dependency on their corresponsing
server side stub.  You can't mix a different proxys and stub types.
Therefore it is ok for a client side interceptor to have a
dependency on the server side interceptor.
Can you describe your AOP problem in more detail.  How
are you going to be remoting POJO with AOP??  With a
proxy?  Who will create the proxy objet?
Regards,
Hiram
--- Bill Burke <[EMAIL PROTECTED]> wrote:
Ok, maybe I shouldn't have said "fatally flawed".
But again, my gut tells
me that it is bad to have a dependency between
server and client
interceptors if it is not absolutely needed.
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Bill
Burke
Sent: Friday, February 21, 2003 4:12 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is
really really bad

I've been thinking and should have posted this
before. Your design is
fataly flawed when I start applying it to the AOP
framework. Your design
assumes that there is a proxy sitting in front of
everything. In AOP this
is not the case.  If you look at
varia/src/org/jboss/aop/plugins/TxSupport.java
you'll see that I had to
combine the clientInvoke and serverInvoke into one
method because there is
no proxy object between the application code and
the object instance.
Ok...no problem you say....Well, think of what
happens when the app
developer decides to remote an AOP'd object. I
will have to have
2 sets of
interceptor chains and have to figure out whether
the call is a
remote call
or local.  Well, I guess I could insert a flag
into the Invocation on
whether the call went through a proxy or not. But
do you see where I'm
going? I don't think its a good design to rely on
the client to handle
transaction semantics. I don't think its a good
idea for the "server" to
have to rely on client logic unless it really has
to.
All and all, my gut tells me that the current
client/tx design will cause
problems. I want interceptor designers in general
to avoid this kind of
dependency.

Bill
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of David
Jencks
Sent: Wednesday, February 19, 2003 11:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] TxInterceptor split is
really really good

On 2003.02.19 09:37 Bill Burke wrote:
What you implemented is fine. My only
problem with it is that I
think it is more logical to let the server
decide if it needs the
tx, and that I think the registration
callback could be avoided
(with minimal redundant client side
bookkeeping) even if the
decision is made on the server side.

I got the impression that this
implementation would also be used
in the other invokers, and that made me
worry about CORBA
interoperability. If this approach will not
be used with the IIOP
invoker, I have no problem with it.

Yes this was my exact worry and still is.
That we'll have to have a
different set of interceptors on the server
side for different
transports.
This is unexceptable because we want each EJB
to be able to
listen to and
service calls from different transports at the
same time.
David, I'm not suggesting to redesign your
code, but is the design
flexible
enough so that we could switch to a
server-side based design?
Iteration
is
a fine thing....
I don't think we will have problems adapting my
current design to use
corba. Before we continue I think we should get
a clear
understanding of
what is supposed to happen when the corba tx
policy and the j2ee
tx support
disagree.  Does anyone know where this is
described in specs?
Basically the corba design says "if there is a
transaction in
the context
it must always be transmitted and imported on
the server" whereas
j2ee does
not always need to import the tx.  The purpose
of the client side
interceptor is to not generate tx branches that
won't be used. I think
that any reasonable corba implementation is
going to follow corba
semantics
and always generate a transaction branch on the
client for the
remote call,
since as far as the corba spec goes, if the call
is made within a tx the
transaction will in fact be used on the server.

In my view the heaviest part of the process is
generating a tx branch on
the client: once it is generated, then it has to
be prepared and/or
committed. The communication overhead on these
messages is
likely to dwarf
any other resource usage.
The choices I can see here are:

1. only generate the branch if it is needed, but
do it right
away.  This is
what I implemented and I think it is simplest
and the only one that is
likely to be comprehensible when someone looks
at it in a week or two.
2. Only generate the branch if it is needed but
do it after the work is
done. I think this is Ole's proposal. This
introduces a lot of
bookkeeping on the client to associate client
side transactions to
branches. I don't think I'd be able to maintain
this code, in a week I
wouldn't remember how it worked. After spending
a day to figure it out,
I'd simplify it to (1).

3. Always generate a branch immediately, but
have the xaresource return
read-only on prepare if the tx did not need to
be imported. This is
unacceptable because it forces 2pc in the case
that there is only
one other
branch.
Don't we need a client side
method-to-method-attributes map
anyway for many
other purposes such as determining if a return
value can be cached?
david

Bill
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit
Inc.
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The
most comprehensive and flexible code editor you can use. Code
faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The
most comprehensive and flexible code editor you can use. Code
faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The
most comprehensive and flexible code editor you can use. Code faster.
C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The
most comprehensive and flexible code editor you can use. Code faster.
C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The
most comprehensive and flexible code editor you can use. Code faster.
C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] TxInterceptor split is really really bad

Reply via email to