Discussions

News: eXtreme Scale: How IBM Supports High Volume and High SLA Applications

  1. IBM's Distinguished Engineer, Kyle Brown, is at it again, explaining how getting away from the idea of 'centralized data' can help improve performance and application scalability.


    "IBM® WebSphere® eXtreme Scale is a general-purpose, high-speed caching solution that can be configured and used in a variety of different designs. However, you can’t just blindly use the APIs provided with WebSphere eXtreme Scale and assume it will reduce the pressure on your overworked database and make your application run faster. Caching as a strategy for improving application performance must be applied judiciously and with care. Likewise, you can’t assume that your application will be resilient in the face of hardware failure unless you consciously plan for that resilience. This article examines a number of best practices that will help you build high performance and highly resilient WebSphere eXtreme Scale applications."

    ----------

    Threaded Messages (18)

  2. Does this compete in the same market as GigaSpaces, Joe ?
  3. Gigaspaces and IBM eXtreme Scale both compete in the market referred to as "Data Grid", "eXtreme Transaction Processing", and/or "Distributed Caching Platform".

    (If you want to know more about the leading implementation in this market, see my sig below. ;-)

    Peace,

    Cameron Purdy | Oracle Coherence
    http://coherence.oracle.com/

  4. Does this compete in the same market as GigaSpaces, Joe ?

    Although both extreme scale and javaspace products can be used for data grids, there's an important and subtle difference. Java spaces came from tuple space and are persistent. Distributed caches on the other hand can remove stale data based on the chosen algorithm. Using either product requires a good understanding of the differences.

    peter
  5. Does this compete in the same market as GigaSpaces, Joe ?

    Although both extreme scale and javaspace products can be used for data grids, there's an important and subtle difference. Java spaces came from tuple space and are persistent. Distributed caches on the other hand can remove stale data based on the chosen algorithm. Using either product requires a good understanding of the differences.

    peter

    Well, I'd never disagree with the last sentence, but... Javaspace tuples have expiry times, so it's trivial to say "store N1 in the space for 10000ms" and after that period it goes away. 

    "Persistency" is very ... vague for JavaSpaces, and depends on implementation; GigaSpaces defines a few ways to achieve it, depending on what you need and what you mean.

    Captcha: "outcasts from." Wow.
  6. Does this compete in the same market as GigaSpaces, Joe ?

    Although both extreme scale and javaspace products can be used for data grids, there's an important and subtle difference. Java spaces came from tuple space and are persistent. Distributed caches on the other hand can remove stale data based on the chosen algorithm. Using either product requires a good understanding of the differences.

    peter

    Well, I'd never disagree with the last sentence, but... Javaspace tuples have expiry times, so it's trivial to say "store N1 in the space for 10000ms" and after that period it goes away. 

    "Persistency" is very ... vague for JavaSpaces, and depends on implementation; GigaSpaces defines a few ways to achieve it, depending on what you need and what you mean.

    Captcha: "outcasts from." Wow.

    Thanks for pointing out the feature in Gigaspaces. The last time I read the javaspace specs, it didn't really address expiring data. I still feel it's important users understand the difference and when to expire data. More specifically, if I have a large dictionary for auto completion, that data probably shouldn't expire. User session data on the other hand should expire if it's not important.
  7. "Thanks for pointing out the feature in Gigaspaces. The last time I read the javaspace specs, it didn't really address expiring data. I still feel it's important users understand the difference and when to expire data. More specifically, if I have a large dictionary for auto completion, that data probably shouldn't expire. User session data on the other hand should expire if it's not important."

    Man, do I dislike this editor.

    Anyway, Peter... JavaSpaces has had lease times for data from the very first public spec, IIRC. It's always been there.

    As far as the TYPES of leases, well... you can always say "expire in 100 ms" *or* you can have "non-expiring" data - by using space.write(myObject, Lease.FOREVER), which, um, either doesn't expire or expires sometime after the sun explodes, I can't remember which offhand.

    Captcha: "walloons Tried."
  8. "Thanks for pointing out the feature in Gigaspaces. The last time I read the javaspace specs, it didn't really address expiring data. I still feel it's important users understand the difference and when to expire data. More specifically, if I have a large dictionary for auto completion, that data probably shouldn't expire. User session data on the other hand should expire if it's not important."

    Man, do I dislike this editor.

    Anyway, Peter... JavaSpaces has had lease times for data from the very first public spec, IIRC. It's always been there.

    As far as the TYPES of leases, well... you can always say "expire in 100 ms" or you can have "non-expiring" data - by using space.write(myObject, Lease.FOREVER), which, um, either doesn't expire or expires sometime after the sun explodes, I can't remember which offhand.

    Captcha: "walloons Tried."
    Thanks for pointing that out. I double checked and you're right. Lease time has always been there. The good thing about getting older is my memory gets worse and others will correct my faulty memory.

    On the topic of expiring data, it differs from the old jcache spec. I probably wrong, but I seem to remember it goes into detail about different algorithms for expiring data, like least frequently used, most frequently used and others.

    I assume gigaspaces also provides similar functionality.
  9. "On the topic of expiring data, it differs from the old jcache spec. I probably wrong, but I seem to remember it goes into detail about different algorithms for expiring data, like least frequently used, most frequently used and others.

    I assume gigaspaces also provides similar functionality."

    I do, too, but I'd have to hunt to find it. I'm not sure what specific expiry capabilities the product has, offhand, and I'd be afraid to say "we can do that!" without actually knowing, like, if we can do that. I know it CAN be done, but I'm not sure what provisions are made at the product level yet.

    Captcha: "sheridan of." How boring!
  10. Does this compete in the same market as GigaSpaces, Joe ?

    Sort of yes, sort of no. GigaSpaces is both cache and app container. Coherence (as I understand it, at least - I'm sure Purdy will step in saying "We can do that!") is a cache.

    Captcha: "treaty cloudier." How the heck do they DO this?
  11. Does this compete in the same market as GigaSpaces, Joe ?

    Sort of yes, sort of no. GigaSpaces is both cache and app container. Coherence (as I understand it, at least - I'm sure Purdy will step in saying "We can do that!") is a cache.

    Coherence provides services to applications; it doesn't try to be an application server itself. Thus far, this has worked out quite well for us, but there's no doubt that there are application server / container capabilities that would be handy for our customers, as long as they remained optional.

    However, since you asked, you can always use Coherence with WebLogic or Glassfish, which are application servers. Coherence is part of WebLogic Suite. In the case of Glassfish, it's an OSGi-based application server, which is pretty cool.

    (BTW Joe, since we've known each other for at least half a dozen years, you can call me "Cameron" ;-)

    Peace,

    Cameron Purdy | Oracle Coherence
    http://coherence.oracle.com/

    p.s. in NYC for Cloud Expo, captcha is "he cabbies"
  12. Hah, "Cameron" -- and yes, I totally understand and agree with your analysis of the placement of Coherence. I just think it's suboptimal, because it means that while you can easily and unobtrusively put Coherence in place - and it's a good product! - I think that higher performance wants the intrusion.

    I was saying "Purdy" because I don't want to be familiar, you know? Trying to be polite and all. :)

    Captcha: "Gold wilbur." I love these.
  13. Hah, "Cameron" -- and yes, I totally understand and agree with your analysis of the placement of Coherence. I just think it's suboptimal, because it means that while you can easily and unobtrusively put Coherence in place - and it's a good product! - I think that higher performance wants the intrusion.

    Sounds like marketing nonsense too me. The facts that Gigaspaces also works as an application server is added functionality to data distribution functionality.

    I can imagine that some things speed up, like a team working faster when you don't need to worry about deployments. But the actual lower level infrastructure that makes data-distribution possible, should not influenced by all the other "application server" features, and if it does, the design is questionable.

    Personally I think Gigaspace is a nice technology, but I'm not convinced that it is 'the' technology for data-distribution. The impact on team performance and on application architecture is high (especially if you use everything Gigaspace throws at you).

    Peter Veentjer
    Multiverse: Software Transactional Memory for Java
    http://multiverse.codehaus.org
  14. "Sounds like marketing nonsense too me. The facts that Gigaspaces also works as an application server is added functionality to data distribution functionality. 

    I can imagine that some things speed up, like a team working faster when you don't need to worry about deployments. But the actual lower level infrastructure that makes data-distribution possible, should not influenced by all the other "application server" features, and if it does, the design is questionable. 

    Personally I think Gigaspace is a nice technology, but I'm not convinced that it is 'the' technology for data-distribution. The impact on team performance and on application architecture is high (especially if you use everything Gigaspace throws at you)."

    (Sorry, I don't know what this editor wants for quotes, and it's kinda wonky.)

    Peter, I wholly and completely respect your POV here, but I don't agree. Look at it this way: EJB2's local interfaces were very much a concession (and an intrusive one) to .. um... some vendors' inability to resolve EJB calls locally if the EJB was colocated with the client. It's definitely not unheard of that one modifies one's architecture to fit the needs of the application.

    GigaSpaces can use the standard APIs like JMS, JCache, etc., to a point (there are some features of the specifications that aren't fully complied with, for example), so you can slot in GigaSpaces without a ton of influence on your architecture, but... I think you're limiting yourself there. If you want the biggest bang for the buck, then you DO modify your deployment architecture to fit the application in question, and I don't think that the cost isn't worth it.

    Team performance metrics are hard for me to gather, but I can tell you that in the teams with which I've worked that have used the full-on GigaSpaces approach to application development and data distribution, the curve was very shallow after configuration issues were worked out. 

    The application architecture impact isn't as heavy as you imply, either - unless you think that Spring, also, has a catastrophic impact on application architecture.

    Again, my two cents and respectfully submitted.

    Captcha: "hemlocks convicted."
  15. (Sorry, I don't know what this editor wants for quotes, and it's kinda wonky.)

    I have the same problem. I made your comments bold.

    Peter, I wholly and completely respect your POV here, but I don't agree. Look at it this way: EJB2's local interfaces were very much a concession (and an intrusive one) to .. um... some vendors' inability to resolve EJB calls locally if the EJB was colocated with the client. It's definitely not unheard of that one modifies one's architecture to fit the needs of the application.

    Perhaps we are talking about different things. I'm talking about the feature Coherence and Gigaspace share: a datagrid. You said that if you want higher performance, you need more intrusion. But if you only need a datagrid, the amount of intrusion should not matter.

    GigaSpaces can use the standard APIs like JMS, JCache, etc., to a point (there are some features of the specifications that aren't fully complied with, for example), so you can slot in GigaSpaces without a ton of influence on your architecture, but... I think you're limiting yourself there.

    It depends. We are just moving away from a Gigaspace heavy approach because a lot of team effort was spend on dealing with Gigaspaces, to an approach where Gigaspace is just a piece of (very important) middleware. We have removed a lot of (unwanted) dependencies and localized them to a few components.

    If you want the biggest bang for the buck, then you DO modify your deployment architecture to fit the application in question, and I don't think that the cost isn't worth it.

    I don't mind having the deployment architecture being Gigaspace based. Atm we gather the components including the applicationcontexts, and create a processing unit. So we have delayed to way to deploy to the last moment. And instead of it being an architecture (hard to change) concern it is now more of a configuration detail (this is how I like my choices).

    Team performance metrics are hard for me to gather, but I can tell you that in the teams with which I've worked that have used the full-on GigaSpaces approach to application development and data distribution, the curve was very shallow after configuration issues were worked out.

    I only have experience with Gigaspace on a project for the last 7 months. But in a lot retrospectives in my team. Gigaspaces came on top of our complaints list. That is why we are trying to reduce dependency on Gigaspaces while developing. Just write normal Pojo's and leave those nasty annotations at home.

    The application architecture impact isn't as heavy as you imply, either - unless you think that Spring, also, has a catastrophic impact on application architecture.

    I have seen Spring code that was totally not understandable (especially if you throw components scan/autowiring in the mix). But that is another discussion "ex Spring enthousiast".

    Peter Veentjer
    Multiverse: Software Transactional Memory for Java
    http://multiverse.codehaus.org
  16. Perhaps we are talking about different things. I'm talking about the feature Coherence and Gigaspace share: a datagrid. You said that if you want higher performance, you need more intrusion. But if you only need a datagrid, the amount of intrusion should not matter.

    Yes, we're talking about different things. But... if we're talking about a pure datagrid, then the coherence and gigaspaces client-side code looks *really* alike. The package names differ, for example, and the actual factory names differ too... but that's a silly thing to complain about, so I think we're still talking at cross-purposes here.

    For the GigaSpaces pure-cache API, see the GigaMap reference. For a Coherence example, see "Creating and Using Coherence Caches." I agree there's some invasiveness, but the amount is about the same for both. 

    Therefore, my conclusion is: you're not getting an invisible cache with any of these products, and the lock-in for any of them is about the same (package and factory names). I don't quite understand your point yet. I'd like to.

    Me>...you can slot in GigaSpaces without a ton of influence on your architecture, but... I think you're limiting yourself there.

    You> It depends. We are just moving away from a Gigaspace heavy approach because a lot of team effort was spend on dealing with Gigaspaces, to an approach where Gigaspace is just a piece of (very important) middleware. We have removed a lot of (unwanted) dependencies and localized them to a few components.

    Definitely a good approach if you can do it - but I still don't see the investment on your part. If you're using a data grid, that's great - but a datagrid in GigaSpaces (and ehcache, and jgroups, and Coherence) has a very simple API where a team *can't* have a heavy approach, because it's not that complicated. (It's a map, for goodness' sake.)

    If you go beyond simple caching, well, that's a more interesting problem (and a smart approach), but ... gosh, I wrote a datastore-neutral benchmark that used JDBC, ORMs, JCR, GigaSpaces, DB4O, Java serialization, memory, an actual local map, mongodb... all with the exact same interfaces in the benchmark's code. For runtime, I suppose the gigaspaces test used a "gigaspaces-heavy" approach - just like the JDBC test used a "JDBC-heavy" approach. In other words: a DAO and a configuration. 

    I can't help but think you're manufacturing a protest here.

    I only have experience with Gigaspace on a project for the last 7 months. But in a lot retrospectives in my team. Gigaspaces came on top of our complaints list. That is why we are trying to reduce dependency on Gigaspaces while developing. Just write normal Pojo's and leave those nasty annotations at home.

    Again, I'm not sure how nasty the annotations are. @SpaceClass is almost an exact analogue for @Entity, @SpaceProperty is the same for @Column, we add routing and index annotations... but you don't need any of those. So yeah, "leave them at home." One of the GigaSpaces improvements on JavaSpaces (IMO) was always the use of POJOs.

    What were the complaints, specifically? Could you send them to me somehow? My email: joeo at enigmastation dot com. 

    Captcha: "off poaching." Yeesh.
  17.     For the GigaSpaces pure-cache API, see the GigaMap reference. For a Coherence example, see "Creating and Using Coherence Caches." I agree there's some invasiveness, but the amount is about the same for both.

        I don't mind working with a product specif api. If you work with jdbc, hibernate, jms, coherence etc, as long as you keep that localized to some specialized classes, everything is alright with me. But as soon as you start seeing it all over the place, then there is a serious problem. Especially if it just as easily could have been taken out. This is not a Gigaspace problem (they provide a lot of different ways to get things done), but a developer issue: selecting the right approach for the job.

        Therefore, my conclusion is: you're not getting an invisible cache with any of these products, and the lock-in for any of them is about the same (package and factory names). I don't quite understand your point yet. I'd like to.

    The problem is not only lock in, but also code that is easy to understand and easy to test.  And the original question was not about lock in, but about a performance claims you made about Gigaspace vs Coherence (so we are definitely not on the original subject anymore).

        Me>...you can slot in GigaSpaces without a ton of influence on your architecture, but... I think you're limiting yourself there.

    It all depends on how you use it. The same goes for Spring, you can create components and wire them up in Spring. Or you can introduce the whole shebang in the application and create something totally not understandable. I also think that every vendor is going to claim that this dependency is not a bad thing.

    Bob Martin wrote a nice post about Guice some time ago.
    http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion
    If you read it (you probably have), you will see multiple solutions; one with a lot of dependencies and one without. I prefer writing a solution that has no dependencies on a framework if there is no need for it (so if I can write code just as easily that has no dependency, then I will prefer that approach). That doesn't mean I don't like frameworks, but I prefer to keep them localized if possible.

        You> It depends. We are just moving away from a Gigaspace heavy approach because a lot of team effort was spend on dealing with Gigaspaces, to an approach where Gigaspace is just a piece of (very important) middleware. We have removed a lot of (unwanted) dependencies and localized them to a few components.

        Definitely a good approach if you can do it - but I still don't see the investment on your part. If you're using a data grid, that's great - but a datagrid in GigaSpaces (and ehcache, and jgroups, and Coherence) has a very simple API where a team can't have a heavy approach, because it's not that complicated. (It's a map, for goodness' sake.)

    It is not just the api, but all the remoting executing space proxies, autowiring, component scans and other junk that make easy to understand code hard to grasp. It could be that my brains are not compatible with this way of working, but I trust them when they something smells. And for my open source project Multiverse, an STM implementation, I do an order of magnitue more complicated stuff, but I'm still able to form a mental picture of the system. In my opinion every system I don't understand, either is:
    - doing very difficult stuff (and I need to spend more time understanding it)
    - made more complicated than needed (and I need to reduce complexity)

        If you go beyond simple caching, well, that's a more interesting problem (and a smart approach), but ... gosh, I wrote a datastore-neutral benchmark that used JDBC, ORMs, JCR, GigaSpaces, DB4O, Java serialization, memory, an actual local map, mongodb... all with the exact same interfaces in the benchmark's code. For runtime, I suppose the gigaspaces test used a "gigaspaces-heavy" approach - just like the JDBC test used a "JDBC-heavy" approach. In other words: a DAO and a configuration.

    I don't mind programming against some vendor specific api's, but as soon they start to appear all over the place, something definitely is wrong. That is also the reason why I liked Spring in the beginning, and think it is a dead end now.

        I can't help but think you're manufacturing a protest here.

    You can do that, but I don't think it would be useful. It is common sense that you want the limit the amount of dependencies, if you don't need it.

        I only have experience with Gigaspaces on a project for the last 7 months. But in a lot retrospectives in my team. Gigaspaces came on top of our complaints list. That is why we are trying to reduce dependency on Gigaspaces while developing. Just write normal Pojo's and leave those nasty annotations at home. But as soon as we are creating the deployment artifacts, we use everything that Gigaspaces provides.

        Again, I'm not sure how nasty the annotations are. @SpaceClass is almost an exact analogue for @Entity, @SpaceProperty is the same for @Column, we add routing and index annotations... but you don't need any of those. So yeah, "leave them at home." One of the GigaSpaces improvements on JavaSpaces (IMO) was always the use of POJOs.

    A Pojo with annotations is not a Pojo anymore. It is just as bad as extending some class, or adding some interfaces. If I was the only one on the teams that was complaining about this issue, I would certainly have given it more time.

        What were the complaints, specifically? Could you send them to me somehow? My email: joeo at enigmastation dot com.


    I will. Thanks for the comments.

  18. I don't mind working with a product specif api. If you work with jdbc, hibernate, jms, coherence etc, as long as you keep that localized to some specialized classes, everything is alright with me. But as soon as you start seeing it all over the place, then there is a serious problem. Especially if it just as easily could have been taken out. This is not a Gigaspace problem (they provide a lot of different ways to get things done), but a developer issue: selecting the right approach for the job.

    Fair enough... but I'm not sure why you painted GigaSpaces with that particular brush if it's not something GigaSpaces is unique about.

    The problem is not only lock in, but also code that is easy to understand and easy to test.  And the original question was not about lock in, but about a performance claims you made about Gigaspace vs Coherence (so we are definitely not on the original subject anymore).

    Well, for pure datagrid operations, the tests and performance claims should be supremely easy to test: get a reference to the cache, put data in, destroy the reference; get another reference to the cache, check to see if that data's still there. Wash, rinse, repeat under load.

    My point about performance was that datagrid was only part of the performance solution here.

    It is not just the api, but all the remoting executing space proxies, autowiring, component scans and other junk that make easy to understand code hard to grasp. It could be that my brains are not compatible with this way of working, but I trust them when they something smells.

    Again, fair enough - you have your own environment and circumstances you have to work through. But... dude, you're throwing around specific terms (from multiple products, by the way) that refer to things that are more or less hidden from you. 

    If you need remote execution, yes, you use a remote proxy. (Horrors! You're using RMI! Oh wait, you're not - CORBA? No... hmm, SOAP? No... oh, this is a space, so I suppose "space proxy" comes in.)

    What's more, that's presented to you as something that beginners in Java should be able to handle: an interface. You configure that interface to call something remote. Just like EJB, just like a SOAP proxy, just like every other proxy.

    If you can't handle an interface as a concept, you have MUCH bigger problems than the ones we're talking about here. I have a hard time believing that's the case.

    Now, there's more: async remote execution muddies the waters, too.. but GigaSpaces uses the same model that java.util.concurrent uses. It's that way because it's kinda necessary if you're doing async invocation, the remote part doesn't factor in except in configuration.

    I understand your frustration, I really do - but you're building a LOT of straw men here.

    (And most of your complaints besides the executors - hey, wait, aren't those a standard java concept? - are based around spring configuration, not GigaSpaces. Even there, you could throw a dart at a crowd of java programmers, and you'll hit someone who understands how to use Spring almost every time.)

    I don't mind programming against some vendor specific api's, but as soon they start to appear all over the place, something definitely is wrong. That is also the reason why I liked Spring in the beginning, and think it is a dead end now.

    See, I'd have felt the opposite. Spring was nice-ish in the beginning but now that i spend less time worrying about configuration, it's a "live end." I don't mind having a dependency in my projects, esp. when everyone else is familiar with that dependency, for better or for worse.

    I only have experience with Gigaspaces on a project for the last 7 months. But in a lot retrospectives in my team. Gigaspaces came on top of our complaints list. That is why we are trying to reduce dependency on Gigaspaces while developing. Just write normal Pojo's and leave those nasty annotations at home. But as soon as we are creating the deployment artifacts, we use everything that Gigaspaces provides.

    Nothing wrong with that! But just like Spring and @Autowired and @Service, @Repository, etc., you don't HAVE to use any gigaspaces annotations in your objects at all. You get slightly suboptimal performance characteristics *sometimes* - it really depends on exactly what you're doing - but you can certainly do it with no intrusions on your code whatsoever.

    But then again, the annotations definitely add value. It depends on what you want.

    A Pojo with annotations is not a Pojo anymore. It is just as bad as extending some class, or adding some interfaces. If I was the only one on the teams that was complaining about this issue, I would certainly have given it more time.

    I disagree (surprise!) but my point was that you didn't need to use any of the annotations; you can safely and easily disregard their use if that doesn't fit your idea of what a POJO is.

    Captcha: "finesse this" -- wow.
  19. Fair enough... but I'm not sure why you painted GigaSpaces with that particular brush if it's not something GigaSpaces is unique about.

    I'm not painting Gigaspace of as a bad product. Only that I'm not convinced that it 'the' solution. I don't have the same feeling I had with Spring as with Gigaspace, even though Gigaspaces is a lot closer to my domain of interest (distributed computing).

    My point about performance was that datagrid was only part of the performance solution here.

    Point taken.

    Again, fair enough - you have your own environment and circumstances you have to work through. But... dude, you're throwing around specific terms (from multiple products, by the way) that refer to things that are more or less hidden from you.

    Too hidden perhaps. I don't like doing discoveries like 'surprise surprise' that layer is remote!

    If you need remote execution, yes, you use a remote proxy. (Horrors! You're using RMI! Oh wait, you're not - CORBA? No... hmm, SOAP? No... oh, this is a space, so I suppose "space proxy" comes in.)

    I don't mind proxies. But I really dislike that annotation in code because you put too much responsibility there. I love remoting proxies,
    but I wire them up in Spring and inject in all locations that need that dependency.

        Now, there's more: async remote execution muddies the waters, too.. but GigaSpaces uses the same model that java.util.concurrent uses. It's that way because it's kinda necessary if you're doing async invocation, the remote part doesn't factor in except in configuration.

    In Java it is very explicit since you are talking to an executor. If you slap on some annotation (especially later), you enter a new world of problems:

    http://pveentjer.wordpress.com/2006/09/04/asynchronous-calls-are-not-an-implementation-detail/

    I don't mind programming against some vendor specific api's, but as soon they start to appear all over the place, something definitely is wrong. That is also the reason why I liked Spring in the beginning, and think it is a dead end now.

    See, I'd have felt the opposite. Spring was nice-ish in the beginning but now that i spend less time worrying about configuration, it's a "live end." I don't mind having a dependency in my projects, esp. when everyone else is familiar with that dependency, for better or for worse.

    Perhaps it is a taste, but it is one I don't like.

    Nothing wrong with that! But just like Spring and @Autowired and @Service, @Repository, etc., you don't HAVE to use any gigaspaces annotations in your objects at all.

    Correct. That is why we are moving from a 'Gigaspaces annotations all over the place' to a 'Lets do that stuff in our Spring configuration if possible'. So we are certainly not moving away from Gigaspaces, we are only localizing it if possible. Most of the Java objects in our system don't need to know anything about the container they are running in.

    But then again, the annotations definitely add value. It depends on what you want.

    I certainly think they do add value, but they should be used with care.

    Peter Veentjer
    Multiverse: Software Transactional Memory
    http://multiverse.codehaus.org