Advising Domain Objects without AspectJ
- Share
-
- |
Read later
Reading List

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
1000000 iteration test for 'Create dynamic proxy using Proxy.newProxyInstance()'
WARMED UP in 16 ms
Iterations ,Total Time(ms) ,Avg(ms)/Iteration ,Transactions/sec
1000000 ,7978 ,0.007978 ,125344.71
1000000 iteration test for 'Create regular object using new'
WARMED UP in 0 ms
Iterations ,Total Time(ms) ,Avg(ms)/Iteration ,Transactions/sec
1000000 ,63 ,0.000063 ,15873015
After pointing out the drastic timing differences between a simple new object instanciation versus a dynamic proxy, he continues by exploring a few options to optimize the advising of domain objects which may have many instances being created. These alternatives are considered in comparison to AspectJ due to the learning curve and effort needed to integrate it into development environments.
First considered is using an object pool but as Batzdorff points out this creates a new set of concerns that must be addressed:
- Returning the advised objects back to the pool when clients are done using them.
- Clearing the state within an object before it is used again by another client.
- Hoping that clients do not keep references to any objects that were released back to the pool. If clients do not cooperate, this could cause all sorts of hard-to-track-down data integrity issues.
- Tuning the maximum size of the pool appropriately. The size would need to be based on the hardware, amount of memory allocated to the JVM, etc.
He also looks at the pros and cons of alternative stategies such as simple Java class extension, static decorating proxies, and dynamic decorating proxies.
Rate this Article
- Editor Review
- Chief Editor Action
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Benefits of AOP for domain model
by
Rickard Öberg
Personally I'm not so worried about the cost of creating objects, as that is done reasonably seldom. The cost per invocation is more interesting. In our case we have tweaked it immensely, and have a base overhead that makes it possible to do about 15-20M "Hello World" calls per second, which is good enough for our purposes.
While I think that the particular implementation of AOP for domain models shown in this article is a bit "kludgy", as too much of it shows through in code, the basic idea is great.
Article Summary
by
Corby Page
Re: Article Summary
by
Corby Page
Re: Article Summary
by
Corby Page
The example doesn't scale well
by
Cristian Herling
The dynamic decorator example is more interesting, as far as I see you are creating a sub-class which acts as the advice and you are binding it to the original class. Now you are down to one decorating sub-class per advised class rather than one sub-class per advised class/advice as with static decoration. Once again this doesn't scale, imagine trying to implement a cross-cutting concern this way, the mushrooming of sub-classes will get out of proportions.
What you really need is a way to create one advice and have it attached to the target classes in a cost-effective manner. Spring and AspectJ do exactly this, but apparently each one has its drawbacks.
Re: Article Summary
by
Rickard Öberg
As for the POJO and persistence problem, I agree that creating an AOP-solution for domain model does require that you have a good persistence framework that supports it. But having it instantiate proxies instead of POJO's is probably going to be the least of your problems. It is much trickier to make a persistence layer that understands that one logical object may be composed of many small fragments. It's not rocket science, but does take some consideration.
The approach we took was to use Jisp/JDBM and plain serialization. We mostly access objects using id's, i.e. a navigational approach, but for the next version we are looking into storing the objects as binary XML (Fast InfoSet) and index them using RDF in a separate store. The tests I've done look very very promising, both for performance and what features this gives you.