> How is this not the general case?  All application code
> accesses the POJO
> through the proxy.  I am going to write a
> constructor-pointcut that will
> always return a proxy instead of the real POJO on construction.
         Here I mean to say if only deep copy is not made.


> The performance hit is the full deep copy not the synchronization.
> Synchronization is only:
>
> realObject = snapshot;
            My thought of pooling is absolute bull shit .
            One Tx ( worst case one invocation)  -- One deep copy even for
transactional locking (which may be sequential access) is also bottleneck.
But currently, its has to be done like that only.
            Even though field versioning is too complex or unclear, we should have
look over that.

Karthik



> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Behalf Of Bill
> Burke
> Sent: Thursday, March 27, 2003 8:20 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
>
>
>
>
> > -----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
>
> How is this not the general case?  All application code
> accesses the POJO
> through the proxy.  I am going to write a
> constructor-pointcut that will
> 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?
>
> There is only one proxy, but you are correct.  For each
> transaction, a full
> snapshot is taken of the real object.  All access to the
> object is done
> through one proxy.
>
> The performance hit is the full deep copy not the synchronization.
> Synchronization is only:
>
> realObject = snapshot;
>
> Remember, we're optimistically locking here.  (Although I'd like to
> optionally provide a transactional lock in the near future).
>
> The alternative solution is much much more complex.  The
> biggest problem
> being, how do you determine when a POJO's state has changed?
> For instance:
>
> Pojo.someHashMapField.get().setValue(blah).  You see my point?
>
> A full deep copy greatly simplifies the code.  Simplicity ==
> robustness.
> Plus I'm not even sure versioned fields would be better
> performing.  Field
> interception is quite expensive and versioned fields would need field
> interception.
>
> The code is under:  varia/src/main/org/jboss/aop/plugins/Version*.java
> testcase is under
> testsuite/src/main/org/jboss/test/aop/bean/Version*.java
> (take a look at the AOP DD under
> testsuite/src/resource/aop/META-INF/jboss-aop.xml too).
>
> 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?
> > >
> > > Bill
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by:
> > > > The Definitive IT and Networking Event. Be There!
> > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > _______________________________________________
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to