Terracotta announces Clustered Spring Runtime

Discussions

News: Terracotta announces Clustered Spring Runtime

  1. Terracotta announces Clustered Spring Runtime (28 messages)

    At the Spring Experience conference in Florida, Terracotta has announced the Clustered Spring Runtime, to transparently provide clustering capabilities to Spring components through the use of a single attribute in the Spring configuration file along with AOP. The goal is to provide clustering capabilities without changing any user code.

    According to the press release, the Terracotta Clustered Spring Runtime will be available in Q2 '06 with Beta availability in Q1 '06 directly from Terracotta, as well as from Interface21.

    Jonas Boner and Bob Griswold emphasized the ease of use of the tool. They said that coders would only have to write correct code (i.e., avoiding obvious race conditions or deadlocks) and the CSR would increase performance and work correctly for the general cases, just as Java does. It also will also provide tools and runtime metrics to help validate that the runtime is working as expected, and help diagnose any problems.

    What do you think?

    Threaded Messages (28)

  2. sounds great[ Go to top ]

    Uhhh, this really sounds great. Unfortunately i ve not visited the Spring conference, so i would love to get some more tech details on this. This thing could eliminate the last power argument i hear all over again that sounds like "dont use Spring, in the case you want to cluster your app in the future, you will have troubles". (despite of the fact that most apps wont be clustered in their entire lifetime and you can still use Spring with EJBs)

    Marc Logemann
    http://www.logemann.org
  3. How much will it cost?[ Go to top ]

    Terracota is great, but it is a commerical product.

    How much will this option cost?
  4. How much will it cost?[ Go to top ]

    Terracota is great, but it is a commerical product.How much will this option cost?

    JBoss actually has all the free OSS components to cluster POJOs in our AOP Remoting stack: failover loadbalancing of distributed requests, and the transparent replication that Terracota offers (JBossCacheAOP). This isn't a new product that we've offered recently, but is actually almost 2 year old tech.

    Bill
  5. How much will it cost?[ Go to top ]

    It sure does, and it works pretty well.

    There is some pretty cogent criticism of what Terracotta are doing, which I found fairly compelling; certainly worth thinking about before running down a complicated development cycle that just assumes this kind of pseudo-identity card game will "just work" for solving general problems in distributed computing.

    The main critics (I saw) are here:

    http://www.devwebsphere.com/devwebsphere/2005/09/opinion_on_apil.html
    http://www.devwebsphere.com/devwebsphere/2005/09/final_word_on_c.html
    http://www.stucharlton.com/blog/archives/000085.html

    (The last one refers to an absolutely classic paper in the field, well worth a read if you never have:
    http://research.sun.com/techrep/1994/smli_tr-94-29.pdf
    )

    The company's CEO responds here:
    http://blog.terracottatech.com/archive/2005/09/object_identity_1.html#more

    When I looked at JBoss Cache (which solved part of the problem I raised here:
    http://www.theserverside.com/discussions/thread.tss?thread_id=37393
    )

    ...I was struck at how "too easy" all this was, and it raised a red flag warning against doing anything too complicated. Masking calls to the network is always risky in anything but the most trivial application. Simplifying problems in concurrency by masking them strikes me as a fool's game. That stuff is HARD, as I'm sure we all know all too well.

    I found this model really useful -- and I'm convinced it's absolutely safe -- for is propogating configuration changes to a managed cluster, each instance of which needs to read some particular (say) configuration object. I have a single (logical) admin node where changes to that configuration object can be pushed out to the cluster, and written into a database. JBoss Cache ended up being really pretty slick for this, and worked really well and easily with JTA. A failure to propogate to any server nicely rolled back changes on all servers. It was a really please "just works" experience.

    But I would be pretty hesitant to do anything hugely complicated with this kind of technology, simply because so little is abstracted. If you hit a problem, you can't fix it in the API (as Billy points out), and the odds of hitting a problem by naively assuming latency is 0 and masked identity could never bite you are, in my estimation, pretty high. That doesn't mean there aren't reasonably large classes of problems that can be safely solved using this approach, but I couldn't imagine starting a company to sell this, particularly when there is already a pretty reasonable open source solution available.

    I was kind of amused while reading about Terracotta that so many of their top people are ex-BEA ... I was just reflecting the other day how annoying it is that WebLogic doesn't seem to have much value add in this area; maybe these guys lost an internal battle and went off and started their own company. More power to them, and it nearly brings a tear to my eye so see this kind of drank-the-kool-aid San Francisco techno-gee-whiz exuberance once again. I hope they all got Aeron chairs out of the deal.
  6. How much will it cost?[ Go to top ]

    Without getting defensive and just to clear the air here:

    1. The "learned folks" quoted as commenting on Terracotta all build competing API-based products and have a vested interest in convincing the community that an API must exist. Some of them, if you read their blogs and other postings, go so far as to assert this stuff is impossible. Mind you, they are not just saying it is a bad idea or an over-simplification but in some cases, downright closing their eyes to the reality of Terracotta's customer use cases and downloadable product--we put our money where our mouth is and let you try the product.

    2. Terracotta is not founded by ex-BEAers. Terracotta is founded by a team of folks who built Java apps in the enterprise and found a massive gap between the app server services and the way the developer views the problem...we are not the only ones claiming that the closer you stay to POJO, the happier you will be. (See Spring, Hibernate, etc.). BEA senior leadership have joined Terracotta because they ran across us in actual customer accounts and BEA customers were very happy with Terracotta.

    3. If talking on the network is hard, then why advocate the end user developer try to solve it inside the business logic? Why not advocate a giant scaled up Sun 128-way machine instead of 64 2-way Linux machines for everyone out there. Clearly scale out, clustering, and the required cross-VM conversations are occurring. You cannot deny that. SOMEONE is going to provide tools to make it easy. And it cannot be every business project, across the Java community, redundantly doing this integration one app at a time.

    No disrespect but how do you refute the case of customers who dropped Terracotta in under third party code? Code that the TC customer doesn't own and cannot rightly disassemble to cluster? We have clustered apps w/o a single edit to source code and in under 1 hour. How do you help that customer with APIs? And how long will it take?

    In the end, the more code you write, the more codified and set-in-stone your application. Push more to the runtime...you will be happier and so will your business management.
  7. XA[ Go to top ]

    Is TC XA compliant? Can I have an XA resource running on a TC cluster? If the coordinator tells you to rollback can you roll back your changes?
  8. XA[ Go to top ]

    Is TC XA compliant? Can I have an XA resource running on a TC cluster?

    Yes. No problem.
    If the coordinator tells you to rollback can you roll back your changes?

    We act just like the JVM acts.

    We are simply extending the regular semantics of Java. We are working (generically) at the VM level, below (and unaware) of any XA-enabled or other JEE deployed app. As a result XA TXs does not impact DSO and vice versa.

    You have 3 different situations.

    1. The client crashes before a DSO TX is even started:
    Nothing to do.

    2. The client crashes right *after* a DSO TX has been started, but has *not* been committed yet (in the middle of a DSO TX):
    We rollback the changes and when the client comes back the initial (old) state is paged in.

    3. The client crashes right *after* a DSO TX has been *committed*:
    All changes are propagated throughout the cluster, and when the client comes back the new state is paged in.

    We have the same semantics as a synchronized(obj) {...} block on a single VM.
    Pessimistic locking with no need for rollback.

    If we where to do anything else we would not act like a single node VM (e.g. not correct/not transparent).

    If you want have more questions I can introduce you to Steve Harris, the lead architect for DSO.
  9. XA[ Go to top ]

    Thanks for the response.

    I just realized that since synchronized-style locks are attached to the thread, you cannot write an XA resource with them, because the locks acquired by an XA resource are associated with Xids, not threads.

    However, I think your DSO server could enlist in a XA transaction. But then it can't decide for itself whether the DSO transaction can be committed - it has to wait for the transaction manager.
  10. XA[ Go to top ]

    Put another way, can it do 2-phase commits in the context of a JTA transaction?
  11. XA[ Go to top ]

    I am curious about it as well.
    Say something like

    myEJB is a stateless ejb with Required TX on all methods

    sharedObject is a Terracotta'DSO shared object, whose updates are propagated accross the cluster, possibly accessed by other threads in my whole application

    In that case I would assume updateSome() is in a new TC transaction, and will be commited even though I rollback the myEJB.doStuff():

    // required TX
    // method of myEJB
    public doStuff() {
      synchronized(My.sharedObject) {
         sharedObject.updateSome(...);
      }
      throw BusinessExceptionToRollbackXAContext();
    }

    now in that sample I would assume that the updateSome() is not to be commited:

    // required TX
    // method of myEJB
    public doStuff() {
      synchronized(My.sharedObject) {
         sharedObject.updateSome(...);
         throw BusinessExceptionToRollbackXAContext();
      }
    }

    Can this be done that way?
    Ie the synchronized in that case is equivalent to something like

     try {
        // do stuff
        commitXAandTC unless someone says xa.setRollbackOnly()
     } catch(AnySortOfBusinessException e) {
        rollbackXAandTC
     }
  12. XA[ Go to top ]

    Thanks for the examples Alex.
    Say something likemyEJB is a stateless ejb with Required TX on all methodssharedObject is a Terracotta'DSO shared object, whose updates are propagated accross the cluster, possibly accessed by other threads in my whole applicationIn that case I would assume updateSome() is in a new TC transaction, and will be commited even though I rollback the myEJB.doStuff():// required TX// method of myEJBpublic doStuff() {  synchronized(My.sharedObject) {     sharedObject.updateSome(...);  }  throw BusinessExceptionToRollbackXAContext();}

    Yes, just like on a single VM.
    now in that sample I would assume that the updateSome() is not to be commited:// required TX// method of myEJBpublic doStuff() {  synchronized(My.sharedObject) {     sharedObject.updateSome(...);     throw BusinessExceptionToRollbackXAContext();  }}Can this be done that way?

    Yes, just like on a single VM.
     try {    // do stuff    commitXAandTC unless someone says xa.setRollbackOnly() } catch(AnySortOfBusinessException e) {    rollbackXAandTC }

    If I understand you correctly, yes.
  13. XA[ Go to top ]

    I am curious about it as well.
    Say something like

    myEJB is a stateless ejb with Required TX on all methods

    sharedObject is a Terracotta'DSO shared object, whose updates are propagated accross the cluster, possibly accessed by other threads in my whole application

    And this has to happen only after commit.

    Come to think of it, how do they select the isolation level given that there is no api? In a single JVM there is only one isolation level, I would answer my own question here, and conclude that TC only supports one isolation level, probably REPEATABLE_READ.
    In that case I would assume updateSome() is in a new TC transaction, and will be commited even though I rollback the myEJB.doStuff():

    I was specifically thinking about a case where the transaction already exists. Which means it is some other thread to later decide whether to commit or roll back (some thread used by the transaction manager.)
  14. XA[ Go to top ]

    We have the same semantics as a synchronized(obj) {...} block on a single VM. Pessimistic locking with no need for rollback.

    Even with pessimistic locking you can get a deadlock (2 threads do a synchronize() on the same 2 objects in a different orders) - so you still have to handle some kind of rollback right?

    I guess if you can get a deadlock using synchronized(obj) {...} then this is an application code bug which would occur even when running in a single JVM and its up to the application developer to fix it. Though they can be quite hard to find sometimes :)

    James
    LogicBlaze
  15. How much will it cost?[ Go to top ]

    Without getting defensive and just to clear the air here:

    1. The "learned folks" quoted as commenting on Terracotta all build competing API-based products and have a vested interest in convincing the community that an API must exist. Some of them, if you read their blogs and other postings, go so far as to assert this stuff is impossible. Mind you, they are not just saying it is a bad idea or an over-simplification but in some cases, downright closing their eyes to the reality of Terracotta's customer use cases and downloadable product--we put our money where our mouth is and let you try the product.

    The point I took away from reading the above links was that having an API ultimately gives you more long-term flexibility and options in terms of making radical underlying change to the implementation. If there are effectively no rules for users of your implementation, then there is a risk that you can't make a change to fix MY P1 revenue-losing problem without breaking your product for your other customers. Too much flexibility in an API CAN be a bad thing; I know this through bitter experience.

    In particular I thought the comparison with the nature of SQL and the kinds of under-the-kimono radical changes they were able to do BECAUSE it is an API with strict rules was food for thought.

    So far I don't think you are addressing the good points very well. You're basically saying, "these guys have an agenda", and "our customers seem to like it." Of course, success is the ultimate arbiter, but there are reasonable points being made against, and I'd prefer to hear a deep analysis of where they miss the mark.
    2. Terracotta is not founded by ex-BEAers. Terracotta is founded by a team of folks who built Java apps in the enterprise and found a massive gap between the app server services and the way the developer views the problem...we are not the only ones claiming that the closer you stay to POJO, the happier you will be. (See Spring, Hibernate, etc.). BEA senior leadership have joined Terracotta because they ran across us in actual customer accounts and BEA customers were very happy with Terracotta.

    My apologies; I jumped to conclusions from looking at your website. I have no doubt that your technology is useful, interesting, and relevant.
    3. If talking on the network is hard, then why advocate the end user developer try to solve it inside the business logic? Why not advocate a giant scaled up Sun 128-way machine instead of 64 2-way Linux machines for everyone out there. Clearly scale out, clustering, and the required cross-VM conversations are occurring. You cannot deny that. SOMEONE is going to provide tools to make it easy. And it cannot be every business project, across the Java community, redundantly doing this integration one app at a time.No disrespect but how do you refute the case of customers who dropped Terracotta in under third party code? Code that the TC customer doesn't own and cannot rightly disassemble to cluster? We have clustered apps w/o a single edit to source code and in under 1 hour. How do you help that customer with APIs? And how long will it take?In the end, the more code you write, the more codified and set-in-stone your application. Push more to the runtime...you will be happier and so will your business management.

    I don't dispute that cross-VM conversations are occurring. As I said above, I think decent points have been made about the potential long-term value of an API vs. an implicit solution, that you aren't addressing. I would add to that further that I have some concerns about the talent required by the guys who have to support this stuff to be able to really understand what's going on, when they can't actually grep for where the API is used.

    As I said, I'm already using the JBoss version of this stuff, and I'm quite pleased with it. So I "get it", at least the AOP part of it. The various proxying techniques we've seen cropping up over the last few years are interesting, and incredibly useful in a variety of contexts, including using closed-source 3rd party code in ways its designers never imagined was possible.

    The issue I see is that, while this whole concept is really sweet for simple cases, trying to get complicated has a lot of risk. Do you deny that? Success nearly always breeds more complexity, as business requirements change, and competition heats up. It's that future complexity that has me, at least, a little worried.
  16. How much will it cost?[ Go to top ]

    The point I took away from reading the above links was that having an API ultimately gives you more long-term flexibility and options in terms of making radical underlying change to the implementation. If there are effectively no rules for users of your implementation, then there is a risk that you can't make a change to fix MY P1 revenue-losing problem without breaking your product for your other customers. Too much flexibility in an API CAN be a bad thing; I know this through bitter experience.In particular I thought the comparison with the nature of SQL and the kinds of under-the-kimono radical changes they were able to do BECAUSE it is an API with strict rules was food for thought.So far I don't think you are addressing the good points very well.

    I think your question here is based on some "over-selling" on my part--sorry. When we say Terracotta is zero API (gasp: is he going to say there is an API?), what we mean is not that you can blindly write any block of Java code and cluster it. What I mean by zero API is "now new API." We have an API (doh: he didn't...grrrr):

    1. java.util.collections interfaces
    2. synchronized{}
    3. wait() / notify()
    4. new()

    etc.

    In some cases, we also use method entry / exit, etc. (other AOP stuff). But, as you can see we have an API. And it is pretty well abstracted. I personally think it is so well abstracted that the folks who offer up an API for clustered caching, and assert that it is required, essentially shadow it.

    I thought about this one for a while but I cannot come up with an example of where an API (that essentially looks like a Map-plus-plus) has abstraction advantages over one that uses Java standard language as its API. I am sure there are examples, but I cannot find them.

    Further, I wish I had thought of this, but I am at the Spring Experience in Florida and Rod Johnson's keynote speech had a focus on quality across the lifetime of his team's framework. Without rehashing what they do, suffice it to say that he asserted the lack of significant API overhead allowed the new 2.0 release to drop-in underneath apps builts for 1.2. (He even demo'ed this right in front of the audience--very kewl).

    The issue I see is that, while this whole concept is really sweet for simple cases, trying to get complicated has a lot of risk. Do you deny that? Success nearly always breeds more complexity, as business requirements change, and competition heats up. It's that future complexity that has me, at least, a little worried.

    I don't deny that success breeds complexity. I view it (same concept, different words) as increasing audience driving increased feature scope (creep). I can't attest to how well we solve "complex" problems since I think "complex" is a subjective word and I can arrogantly assert that Terracotta has done "complex" things only to learn that you meant something more (or that customers take us to difficult places in the future). We will have to wait and see, but for now I will hang my hat on the fact that the API-based solutions strive to look identical to the core Java API and AOP folks like Adrian Colyer and Joans Boner (AspectJ) are out ahead of Terracotta solving really hard problems generically with usually nothing more than the Java Language spec to guide them.
  17. How much will it cost?[ Go to top ]

    Thanks Ari, this does a lot to help me better understand where you guys have taken this. This does sound cool, perhaps even revolutionary.

    I'd be nervous about overloading synchronized, etc. The point made back in the middle-dark ages of distributed computing Waldo, et al ( http://research.sun.com/techrep/1994/smli_tr-94-29.pdf ) was that the differences you are proclaiming to mask are so profound in terms of the complexity of understanding all the different possible ways to shoot yourself in the foot, that it really wasn't a good idea to do it this way. They write,
    It is the thesis of this note that this unified view of objects [namely, "On the view that all objects are essentially the same kind of entity, these differences in relative location are merely an aspect of the implementation of the object."] is mistaken. There are fundamental differences between the interactions of distributed objects and the interactions of non-distributed objects. Further, work in distributed object-oriented systems that is based on a model that ignores or denies these differences is doomed to failure, and could easily lead to an industry-wide rejection of the notion of distributed object-based systems.

    You are essentially saying, I think, that this paper is wrong. Waldo, et al, were writing in very general terms about complicated distributed topologies for solving general problems. The common case now is high-availability clusters, all running exacdtly the same software; that does simplify the problem space, maybe enough to render their argument invalid or irrelevant.

    On the other hand, I've been plenty of times by a wrongly-placed synchronized keyword that was right trillions of times before finally deadlocking a JVM because of, say, undocumented container behaviour. Getting it right in all cases in a single JVM is bloody hard. Adding to that the fact that I can't tell by looking (or grepping) whether a given synchronized keyword is this JVM, or all JVMs, strikes me as frightening to say the least. I think I'd prefer at least the option of being able to say myObject.clusterSynchronize(), clusterWait(), etc., as a better long-term solution than changing the language, which is essentially what you guys are doing.

    Time will certainly tell; maybe you are on to the next big thing. I believe the functionality you are offering is absolutely spot on. But I think overloading synchronized, wait, etc., is probably not the right approach long-term. Waldo's paper runs through the cycle of technologies over decades: message passing, procedures, objects; and how each time, this signalled the age when we would finally be able to stop caring about which machine held what. Perhaps the cycle has finally hit the right silver bullet in aspects, though personally, I tend to doubt it.
  18. How much will it cost?[ Go to top ]

    Adding to that the fact that I can't tell by looking (or grepping) whether a given synchronized keyword is this JVM, or all JVMs, strikes me as frightening to say the least. I think I'd prefer at least the option of being able to say myObject.clusterSynchronize(), clusterWait(), etc., as a better long-term solution than changing the language, which is essentially what you guys are doing.Time will certainly tell; maybe you are on to the next big thing. I believe the functionality you are offering is absolutely spot on. But I think overloading synchronized, wait, etc., is probably not the right approach long-term.

    With respect to Waldo's research essentially, most apps get deployed on 2 or more app server instances (2 more more JVM's, as a result). Additionally, the app server is providing services (like the Servlet interface) that make it akin to an OS for the Enterprise Java developer. So people must cluster, and they are simultaneously relying on their "OS" to provide certain standard API's and services. We wedge in right there (between the business logic and the container) with no semantic violation of intent or expectations (example: ServletSession for a non-clustered app does not call session.setAttribute() yet with Terracotta this object will still be properly replicated as part of session when its fields are modified). I think that without Terracotta, many folks are left not clustering due to added complexity and if we were to offer an API to those folks, they would see our solution as they see existing clustered caches: trading one complexity for another. We hear consistently that folks would rather not cluster than fundamentally diverge from the Java contract ("==" and pass-by-reference) they enjoy when domain modeling.


    That being said, I totally agree that there are better ways to deliver pieces of our functionality:

    1. We have an Eclipse plug-in in the impending 2.0 release that reads our XML config and paints your source code clearly denoting clustered locks and clustered objects as you write your code. This is much like what you are suggesting.

    2. Our existing 1.1 Management Console shows deadlocks on a cluster-wide basis.

    as for clusteredSynchronized{}, I believe AspectJ and JDK 1.5 are going to lead the way--out in front of Terracotta--and some day we will be more apparent near the source code yet continue to avoid changing the code base or perturbing the domain model.

    This announcement on TSS is different from the generic discussion on transparent clustering, IMO. Terracotta focuses on selling "drop-in" modules separate of the core platform. We can cluster things like Spring's internals, for example, without any help from you--the end developer. And Interface21 likes this becuase they don't have to deliver any SPI's to Terracotta AND they don't violate their core value proposition of SIMPLE / POWERFUL when clustered. While anyone is welcome to purchase our core and code up an app, cognizant that the app will be clustered at production time, customers of our clustered Spring runtime (plus our clustered WLS session replacement, and many more modules to come) needn't worry about clustering at all.

    Thanks for asking great questions and helping me to better understand the challenges we will face as our product matures. Very helpful. (And thanks for the supportive words as well.)

    --Ari
  19. How much will it cost?[ Go to top ]

    1. We have an Eclipse plug-in in the impending 2.0 release that reads our XML config and paints your source code clearly denoting clustered locks and clustered objects as you write your code. This is much like what you are suggesting.

    That's an interesting idea, although not much use to me as a vi user.... :) And, well, greppity greppity grep grep. I like (read: prefer) grep. And cscope.
    2. Our existing 1.1 Management Console shows deadlocks on a cluster-wide basis.as for clusteredSynchronized{}, I believe AspectJ and JDK 1.5 are going to lead the way--out in front of Terracotta--and some day we will be more apparent near the source code yet continue to avoid changing the code base or perturbing the domain model.

    When you say "shows deadlocks", I assume you mean "after the fact"? Customers tend to highlight them as well....

    As for annotations, I think they are really pretty ugly, but I'm sure one gets used to them, and clearly it is the way forward. I'm also vaguely suspicious of the notion that changing an annotation somehow is less test-cycle-inducing than just changing the code. Clearly declarative transactions have been a point of high leverage in the last software wave, and I suppose declarative clustering could well be the next. With transactions, though, you always have the choice of using the transaction API explicitly, or doing things declaratively.
    This announcement on TSS is different from the generic discussion on transparent clustering, IMO. Terracotta focuses on selling "drop-in" modules separate of the core platform. We can cluster things like Spring's internals, for example, without any help from you--the end developer.

    Agreed. Thanks for straying to far off-topic; this has been very interesting.
  20. How much will it cost?[ Go to top ]

    JBoss actually has all the free OSS components to cluster POJOs in our AOP Remoting stack: failover loadbalancing of distributed requests, and the transparent replication that Terracota offers (JBossCacheAOP). This isn't a new product that we've offered recently, but is actually almost 2 year old tech.Bill

    chhh :-D. spare us.
  21. JBoss POJOCache[ Go to top ]

    One of the ideas that would hopefully make it on to the JBoss roadmap is Ben Wang's PojoCache, which is essentially a transparent clustering layer for Pojos using Java5 annotations.

    Ben released some initial info on PojoCache in this OnJava article

    This will be built on top of JBossCache, and will have all the distributed, transactional, failover features of JBossCache.
  22. JBoss POJOCache[ Go to top ]

    One of the ideas that would hopefully make it on to the JBoss roadmap is Ben Wang's PojoCache, which is essentially a transparent clustering layer for Pojos using Java5 annotations.Ben released some initial info on PojoCache in this OnJava articleThis will be built on top of JBossCache, and will have all the distributed, transactional, failover features of JBossCache.

    You make it sounds like it doesn't exist yet. It is already out there, and it's quite straightforward to use.
  23. One of the ideas that would hopefully make it on to the JBoss roadmap is ...

    Manik: You are on the JBossCache dev team, aren't you? http://jboss.org/jbossBlog/blog/manik/
  24. Clustering Spring apps[ Go to top ]

    This thing could eliminate the last power argument i hear all over again that sounds like "dont use Spring, in the case you want to cluster your app in the future, you will have troubles".

    Clustering Spring apps has never been difficult. We've been helping customers do it with Coherence for years ..

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  25. Clustering Spring apps[ Go to top ]

    Cameron, I don't really get what it means "clustering Spring apps". Another attribute in bean definition?
    Handy, yes, marketing thing, yes, but no more.
    I'd actually just do it manually...
  26. Registration starts at 4:00pm EST you could at least wait until then...

    s/has/will/

    Bahhh press releases....

    Neat idea though, maybe I'll stop by and listen to the presentation...
  27. They explicitly gave me permission, dude! :)
  28. tribution Huh !!!![ Go to top ]

    But Isn't the idea is to avoid distribution of the components in the first place unless I got my POEAA(Martin Fowler) wrong ? . Should n't I relly on hardware clustering
  29. This is certainly interesting stuff.

    As folks have already commented there have been a variety of different remoting technologies around for a while to distribute POJO based applications. e.g. Spring Remoting has been around for a while. If you need to cluster your services to support load balancing and failover you can use Lingo which implements POJO/Spring Remoting using JMS queues or topics. As an aside Lingo now supports the SCA annotations for marking methods as one-way asynchronous etc.

    Though one of the things that's cool and innovative in Terracotta is its use of synchronized, wait() & notify() in a clustered environment for implementing distributed locking and notifications. I think Terracotta deserve credit for that - its a great idea and an interesting use of AOP. Their Distributed Shared Objects look interesting too.