Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration
when I thought about this, I was trying avoir the current construct :
B oldB = a.getB();
C oldC = a.getC();
try
{
a.setB(b);
a.setC(c);
}
catch(Throwable t)
{
a.setB(oldB);
a.setC(oldc);
}
and I was trying to find a way to make atomic Deployment within
deployers. Deploy all or nothing.
Bill, with AOP fwk would that be possible to know how many bytes
an object takes effectively ?
((ObjectStat) pojo).getBytesInMem();
Instrument the pojo to iterates over its fields and computes
its memory footprint.
julien
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Karthik
Sent: Thursday, March 27, 2003 1:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Hi bill,
The versioning of POJO is very good. I have some issues here. If I
version a object, then I have to maintain all the state in the same POJO
BB How is this not the general case? All application code accesses the POJO
BB through the proxy. I am going to write a constructor-pointcut that will
BB always return a proxy instead of the real POJO on construction.
which is not the general case and will bloat the code. The states are
maintained in the helper classes. Also defining each POJO as versioned is
meaningless. If new proxies are created for each transaction with the deep
copy of all the state or maintain a pool and synchronize the state after
update, it will become real performance bottleneck.How do you tackle this
problem?
BB There is only one proxy, but you are correct. For each transaction, a full
BB snapshot is taken of the real object. All access to the object is done
BB through one proxy.
BB The performance hit is the full deep copy not the synchronization.
BB Synchronization is only:
BB realObject = snapshot;
BB Remember, we're optimistically locking here. (Although I'd like to
BB optionally provide a transactional lock in the near future).
BB The alternative solution is much much more complex. The biggest problem
BB being, how do you determine when a POJO's state has changed? For instance:
BB Pojo.someHashMapField.get().setValue(blah). You see my point?
BB A full deep copy greatly simplifies the code. Simplicity == robustness.
BB Plus I'm not even sure versioned fields would be better performing. Field
BB interception is quite expensive and versioned fields would need field
BB interception.
BB The code is under: varia/src/main/org/jboss/aop/plugins/Version*.java
BB testcase is under testsuite/src/main/org/jboss/test/aop/bean/Version*.java
BB (take a look at the AOP DD under
BB testsuite/src/resource/aop/META-INF/jboss-aop.xml too).
BB Bill
Correct me if I am missing something.
Where or when can get the code from the CVS?
Thanks
Karthi
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Bill
Burke
Sent: Thursday, March 27, 2003 10:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Jeff
Haynie
Sent: Wednesday, March 26, 2003 11:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
JBoss Remoting is much more fabulous. We need to get the
word out on
it...
I need to write some darn docs.. Too busy trying to get a
new release
out on our side. Not enough hours in a day.
I totally agree. And yes, a constructor pointcut is the
way to go.
The only downside of constructor pointcuts is that
reflection bypasses
the interception!
Same thing with field interception. The problem is that unlike
methods, you have to modify the bytecode of the calling logic.
Could you dynamically do an insertBefore into the
CtConstructor of the
advised class which would do the interception, even on reflection?
I'm not sure...The problem with Versioning and Remoting is
that a proxy
object is required. You have to return a different object
than the one
actually constructed. You getting me? I'm not sure if this
can be done
within bytecode manipulation. I'll have to ask the Javassist guys.
I will write some testcases that put the whole stack together with
constructor pointcuts.
I'm also working on the concept of an abstract Container.
But you got
me thinking that constructor pointcuts may be enough...
I was just going to email you about the Container - just
looking through
the code. Is this just the ability to create an AOP namespace or
something?
I guess you could think of it in that way and use it in that
way, but the
original intent was to handle things like dynamic loading through the
persistence mechanism much in the same way an Entity Bean
Container handles
invocations on objects that are not in memory yet. You get
what I'm saying?
RE: Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration
hey hey, let's take it online new site is up with NUKES and it rocks,
you can see who is on and stuff
marcf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of julien viet
Sent: Thursday, March 27, 2003 10:11 AM
To: Bill Burke
Subject: Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration
when I thought about this, I was trying avoir the current construct :
B oldB = a.getB();
C oldC = a.getC();
try
{
a.setB(b);
a.setC(c);
}
catch(Throwable t)
{
a.setB(oldB);
a.setC(oldc);
}
and I was trying to find a way to make atomic Deployment
within deployers. Deploy all or nothing.
Bill, with AOP fwk would that be possible to know how many
bytes an object takes effectively ?
((ObjectStat) pojo).getBytesInMem();
Instrument the pojo to iterates over its fields and computes
its memory footprint.
julien
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Karthik
Sent: Thursday, March 27, 2003 1:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Hi bill,
The versioning of POJO is very good. I have some issues
here. If I
version a object, then I have to maintain all the state in
the same
POJO
BB How is this not the general case? All application code
accesses the
BB POJO through the proxy. I am going to write a
constructor-pointcut
BB that will always return a proxy instead of the real POJO on
BB construction.
which is not the general case and will bloat the code. The
states are
maintained in the helper classes. Also defining each POJO as
versioned is meaningless. If new proxies are created for each
transaction with the deep copy of all the state or maintain a pool
and synchronize the state after update, it will become real
performance bottleneck.How do you tackle this problem?
BB There is only one proxy, but you are correct. For each
transaction,
BB a full snapshot is taken of the real object. All access to the
BB object is done through one proxy.
BB The performance hit is the full deep copy not the
synchronization.
BB Synchronization is only:
BB realObject = snapshot;
BB Remember, we're optimistically locking here. (Although
I'd like to
BB optionally provide a transactional lock in the near future).
BB The alternative solution is much much more complex. The biggest
BB problem being, how do you determine when a POJO's state
has changed?
BB For instance:
BB Pojo.someHashMapField.get().setValue(blah). You see my point?
BB A full deep copy greatly simplifies the code. Simplicity ==
BB robustness. Plus I'm not even sure versioned fields would
be better
BB performing. Field interception is quite expensive and versioned
BB fields would need field interception.
BB The code is under:
BB varia/src/main/org/jboss/aop/plugins/Version*.java
BB testcase is under
testsuite/src/main/org/jboss/test/aop/bean/Version*.java
BB (take a look at the AOP DD under
BB testsuite/src/resource/aop/META-INF/jboss-aop.xml too).
BB Bill
Correct me if I am missing something.
Where or when can get the code from the CVS?
Thanks
Karthi
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Bill
Burke
Sent: Thursday, March 27, 2003 10:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Jeff
Haynie
Sent: Wednesday, March 26, 2003 11:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects
1st iteration
JBoss Remoting is much more fabulous. We need to get the
word out on
it...
I need to write some darn docs.. Too busy trying to get a
new release
out on our side. Not enough hours in a day.
I totally agree. And yes, a constructor pointcut is the
way to go.
The only downside of constructor pointcuts is that
reflection bypasses
the interception!
Same thing with field interception. The problem is
that unlike
methods, you have to modify the bytecode of the calling logic.
Could you dynamically do an insertBefore into the
CtConstructor of the
advised class which would do the interception, even on
reflection?
I'm not sure...The problem with Versioning and Remoting
is that a
proxy object is required. You have to return a different object
than the one
actually constructed. You getting me? I'm not sure if this
can be done
within bytecode manipulation. I'll have to ask the
Javassist guys.
I will write some testcases that put the whole stack
together
with
constructor pointcuts.
I'm also working on the concept
