GigaSpaces Document API and JAXb

I wrote this article and the plugin that ships with it last year when GigaSpaces 8.0 was released and realized that I never finally published both the sources and article so here it is!

GS8 introduced a new way to store data in a flexible manner: the space document.

Document is an evolutive object storage that allow users to dynamically add or remove properties and even dynamically add indexes on any property.

Some of my clients uses XML to model their data and where quite happy to be able to seamlessly be able to make evolve their Space object as easily (or even more easily) as their XML schema.

As this need sounded quite interesting to me I build a small plugin for JAXb that allows to generate Document compliant classes directly from your XML Schemas.

You can download the source code and test it from here: https://github.com/fastconnect/jaxb-gigaspaces

Formation publique GigaSpaces XAP en Juin : et pourquoi pas vous ?

Vous êtes développeur, architecte, chef de projet, journaliste spécialisé, blogger, passionné par les architectures distribuées et/ou les concepts Cloud, ou simple curieux ?

Vous êtes dans un des cas suivants :

  • Vous avez toujours rêvé de comprendre comment on peut construire des applications à hautes performance aptes à monter en charge aisément; c’est à dire qui ne nécessitent pas de réinventer la roue à chaque fois que votre application doit évoluer, en nombre d’utilisateurs, en volumes de données, en nombre de requêtes…
  • Vous percevez que la technologie GigaSpaces XAP peut vous aider dans votre projet, mais vous avez besoin d’en savoir plus, parce que quand même ça parait trop beau…
  • On vous a demandé de monter en compétences sur GigaSpaces XAP, mais les quelques centaines de pages de la doc vous effraient, et vous ne savez pas par quel bout attaquer la bête.
  • Vous voulez comprendre pourquoi ces allumés chez FastConnect pensent que c’est une alternative à moindre coût avec un meilleur rapport prix/performance, aux plates-formes JEE (accompagnée de leur lot de composants additionnels et de coût d’intégration)
  • Vous vous demandez qui sont les personnes qui se cachent derrière ce blog et vous viendriez bien voir ça de vos propres yeux…
    • Et vous n’avez pas peur de faire évoluer votre perception des architectures distribuées !

      N’hésitez plus un seul instant, et venez suivre la formation publique, officielle, sur la plate-forme GigaSpaces XAP. Cette formation est réalisée dans le cadre du programme GigaSpaces University et est animée par des experts FastConnect confirmés et certifiés par GigaSpaces !

      Pour vous inscrire, rien de plus simple, c’est là : http://www.amiando.com/GigaSpacesPublicTrainingEUJune2011.html

      Cette formation sera animée par Luc, notre gourou sur les architectures distribuées qui compte à son actif quelques dizaines de missions d’expertise dans ce domaine depuis plusieurs années autour des problématiques de montée en charge, de performance, de répartition de charge, de résilience, et j’en passe.

      Enfin, FastConnect étant organisme de formation officiel, cette session de formation peut rentrer dans le cadre du programme de formation de votre entreprise. Contactez nous à training ( a t ) fastconnect.fr pour plus d’informations à ce sujet.

      N’attendez pas pour vous inscrire. Le nombre de places est limité.

      Au plaisir de vous voir !

      Présentation Data Grid au Paris JUG

      Demain soir à 19h30 se déroule le traditionnel Paris JUG, événement réunissant la communauté Java parisienne autour d’un certain nombre de sujets d’actualité. Je précise pour les non initiés ;-)
      Il est vrai que d’ordinaire nous ne postons jamais au sujet de cet événement car d’autres confrères le font très bien.
      Cependant, il me semblait important de mentionner la présentation Data Grid qui me semble très intéressante et d’actualité dans un certain nombre de projets.

      Qu’est ce que le Data Grid ?

      Tous ceux qui sont confrontés à des problématiques de temps d’accès aux données ou de traitements massifs de ces données recherchent des solutions alternatives aux bases de données relationnelles.
      Les Data Grid en mémoire permettent de clusteriser la mémoire d’un parc hétérogène de machines tout en fournissant un accès simple (clef valeur, ?QL, template d’objet) et transactionnel, à cet espace mémoire virtualisé.
      Le stockage des données en mémoire est fiabilisé par un certain nombre de mécanismes et le Data Grid fournit les indispensables mécanismes d’intégration au SI dont, notamment, les bases de données existantes.
      Lorsqu’on revient aux fondamentaux; j’aime considérer les technologies en identifiant leur impact sur les éléments matériels sous-jacents (CPU, mémoire, disque, réseau); on se rend compte que les technologies Data Grid fournissent une réponse très adaptée dans beaucoup de situations car les temps d’accès et la bande passante de la mémoire sont infiniment supérieurs à ce que peuvent proposer les disques.
      Évidemment, on peut toujours payer très cher pour essayer d’atteindre les mêmes performances que la mémoire avec des disques spécialisés, mais le veut on ?
      Oui me diront certains, ça rassure ! Mais c’est un autre débat et puis ces temps-ci, en période de crise, ça fait pas très classe ;-)

      La base de données change de rôle

      En tant que partenaire GigaSpaces, un des leaders de ce domaine, nous voyons de plus en plus d’entreprises de toute taille qui démarrent des études afin de choisir le Data Grid qui permettra à leurs projets stratégiques de gérer les problématiques de stockage haute-performance et de traitements de données.
      Depuis un peu plus de 3 ans environ, une grosse partie de notre activité a été de concevoir avec nos clients, et mettre en production, des systèmes stratégiques fondés sur les technologies Data Grid. Non seulement ça marche, mais les performances sont au rendez vous :
      – plusieurs dizaine de milliers d’appels par seconde
      – des temps de réponse inférieurs à la milliseconde sur des réseaux classiques 1GB
      tout çà sur une « lame » d’entrée de gamme à quelques milliers d’euros pièce.

      Lorsqu’on voit la prolifération d’offres alternatives aux bases de données relationnelles, il est désormais clair que le rôle de la base de données est en train de changer (ou a déjà changé pour certains) dans le système d’informations.
      La base de données a imposé son hégémonie dans nos systèmes d’information depuis des années et a fait la richesse de certains acteurs du secteur, mais il est désormais acquis que la base de données ne peut pas monter en charge sans faire la richesse des vendeurs de matériel.
      D’ailleurs, curieusement, dans certains cas, ce sont les mêmes ;-)

      Le Data Grid s’est donc imposé avec le temps; projet après projet, secteur d’activité après secteur d’activité comme la solution alternative à la base de données, notamment lorsque celle ci se trouve sur le chemin critique des transactions.
      Des pionniers de ce secteur comme GigaSpaces martèlent ce message depuis une dizaine d’années maintenant.
      D’autres utilisateurs et fournisseurs d’infrastructures massivement distribuées ont utilisé un certain nombre de concepts  d’informatique distribuée sous-jacents aux technologies Data Grid dans leurs infrastructures internes.
      Je pense notamment à Google, Amazon, Facebook qui n’ont pas eu le choix, pour des raisons économiques que de créer des alternatives pour stocker et exploiter de manière efficace leurs données.
      Comme il faut rendre à César ce qui appartient à César on peut même dire que ces acteurs incontournables du Web poussent à leurs limites les technologies traditionnelles et dans certains cas poussent (ou tirent comme vous voulez) l’innovation. Le concept MapReduce a été popularisé par Google par exemple.

      Le Data Grid, la boite à outils pour le traitement massif de données

      Lorsqu’il m’arrive de présenter GigaSpaces, je fais souvent l’analogie entre GigaSpaces et les concepts sur lesquels s’appuient ces énormes infrastructures en indiquant que GigaSpaces peut être vu comme une technologie permettant de productiser, et rendre accessible de manière simple un ensemble de concepts d’informatique distribuée.
      Cela nous permet à nous, architectes et développeurs, d’avoir les outils permettant d’assurer la performance et la scalabilité de nos applications distribuées.
      D’ailleurs à ce propos, je voudrais mentionner cet article qui explique bien un certain nombre de principes de l’informatique distribuée : http://www.hfadeel.com/Blog/Files/ArtofDistributed.pdf tels que les concepts de Grid Computing, de Master Worker ou de MapReduce.

      Au delà de la gestion des données en mémoire, de manière fiabilisée et très performante, le Data Grid permet de paralléliser les traitements sur les données en permettant l’implémentation de patterns tels que Master Worker ou Map Reduce.

      Les capacités du Data Grid sont multiples, les technologies Data Grid sont matures (car d’autres ont débuggé pour vous, vous savez ce que c’est ;-) ), et les cas d’utilisation foisonnent, tous secteur d’activités confondus.

      Voilà, j’espère que je vous aurai donné envie de venir assister à cette présentation Data Grid si vous n’étiez déjà convaincus, et je serai présent ainsi qu’un certain nombre de nos consultants (dont Jean-Michel qui participe à cette présentation) pour discuter de tout çà avec vous.

      Pour venir : http://www.jugevents.org/jugevents/event/16041
      Les détails de la présentation : http://www.parisjug.org/xwiki/bin/view/Meeting/20090512

      Java soft-references – usage consequences on a memory based architecture (data grid/caching, cloud)

      My previous article on java references introduced the java referencing model with the nice features that it can include. One of them the soft-reference was as I explained very useful for cache and buffers in a VM.

      In this article I will discuss the particular effect that using soft-references can have on a java cloud or data-grid. We will particularly focus on GigaSpaces as it is the currently more active solution as a Cloud-Computing end-to-end application server and build in java.

      When a developer uses soft reference, he allows the JVM to take control on a part of the heap and manage it just the way she likes. The developer in that case really has no control at all. Even if the Garbage Collection cycles are controlled by JVM the developer can try to invoke GC (unless the -XX:+DisableExplicitGC is on but we really not consider this as a good practise). As all of us know calling an explicit GC is not a hundred percent guaranty of having a real full GC cycle but certainly help to reduce the heap in different scenarios. However this will for sure have no impact at all on the soft-reference usage.

      So “why can this be bad?” After all the goal of soft-reference is too be a cache, use the heap but still guarantee the security of the JVM (no risk of OutOfMemoryException). Basically if there is no direct impact on most of application we can wonder what is the impact of the soft-reference on heap monitoring. Indeed the objects held by soft-reference are here but are not consuming heap in a “risky way”. Basically they cannot be considered as responsible for any memory leak or even “real usage”.

      However a monitoring of the heap may make people think that the heap is really used and that basically they have a risk for their application. If people can be educated and can find out that memory is related to soft-reference, there is no statistics in the JVM that clearly shows it.

      The problem is even more relevant when an application uses a self-monitoring to take actions at given SLA. This is basically what will and should happen in many cases on a java cloud. We can this way enter in SLA being triggered without any good reason.

      This is why soft-reference usage must be used with caution in those environments.

       

      If we look at the example of GigaSpaces:

      -As a cloud provider GigaSpaces help you to monitor and to define SLAs based on the heap and memory usage. As we already saw this can be really dangerous (depending on your SLA action) if many soft references are used. We can run in scenarios where some part of your application will not be relocated on a VM because of these soft-references.– I want to really emphasis that such scenarios will mostly be bad usage of soft-reference in the application code or sometimes some really extreme situation that I will detail later.

      -As a data-grid vendor, GigaSpaces has a very nice memory protection feature that allows the Spaces to protect themselves from OutOfMemory by cancelling write operations performed on it. These protections are based on memory SLAs (see http://www.gigaspaces.com/wiki/display/XAP66/Memory+Management+Facility#MemoryManagementFacility-MemoryUsage) and implies the same impact when the memory is consumed by soft-references.

      Again the scenarios that will push to run in such situations are rare and quite extreme. But let details one of them that can happen with GigaSpaces.

      The GigaSpaces software uses soft-reference in his communication protocol LRMI to manage buffers. In most situations this will never cause any high heap consumption. However when many client connect to the space to request concurrently big object or many small objects we may run in a situation where many buffers are created and will consume memory. This kind of scenario may happen typically in Grid Computing scenarios, when the whole Grid (we encounter mostly DataSynapse or Platform systems) tries to connect and perform request on a single data-grid node.

      The question that comes next is: “so what can I do in such a case?”

      The truth is that there is no easy answer to this question. The parameter -XX:SoftRefLRUPolicyMSPerMB help to tune the soft-reference garbaging in SUN JVM. However this parameter is not part of the java specification. It does indeed not exist in other JVM.

      I will therefore recommend using in such use-case a SUN JVM to be able to perform the tuning that my application will require.

      I don’t know if any of you have been involved in similar situations, and I wonder how you managed to handle this.

      Petit Déjeuner GigaSpaces – 17 Novembre 2008

      GigaSpaces organise, en partenariat avec FastConnect un Petit Déjeuner Exécutif le 17 Novembre 2008 dans les Salons Etoile Wagram à Paris : http://www.gigaspaces.com/Upcomingevents.
      Si vous voulez vous inscrire, c’est aussi simple que çà.

      L’objectif de ce petit déjeuner est de présenter comment les solutions de Grilles de Données (DataGrid) et de serveur d’application virtuel (Scale Out Application Server) de GigaSpaces peuvent aider à:

      • garantir la performance de vos applications, quels que soient les volumes de données traitées
      • assurer le bon fonctionnement de vos applications en cas de charge imprévue du système

      4 présentations sont prévues à l’heure actuelles, dont 3 animées par des clients et partenaires de GigaSpaces.

      J’animerai la première présentation, en introduisant la problématique de gestion de la performance et de garantie des temps d’accès sous contrainte de volumes croissants à travers l’utilisation de grilles de données en mémoire et de techniques de virtualisation applicative.
      L’objectif pour moi est de présenter comment des technologies comme GigaSpaces permettent de déléguer la gestion des Non Functional Requirements à une infrastructure implémentant les bonnes pratiques de scalabilité et de performance capable de fournir la scalabilité linéaire nécessaire aux architectures techniques actuelles.

      Ensuite, Luc Taguet, Responsable de l’Architecture Technique pour les Dérivés Actions chez Calyon présentera la mise en oeuvre du produit GigaSpaces Enterprise DataGrid en combinaison avec DataSynapse GridServer dans le cadre du déploiement d’une nouvelle solution de pricing distribué à la Direction Informatique des Marchés de Capitaux.

      Mandhir Gidda, Head of Technical Architecture chez Avenue A Razorfish, un partenaire britannique de GigaSpaces, présentera un framework SOA de nouvelle génération basé sur GigaSpaces qui est utilisé chez un grand opérateur mobile anglais et qui met à profit les capacités de la plate-forme.

      Enfin, Uri Cohen, Product Manager GigaSpaces présentera la dernière version 6.6 de GigaSpaces Extreme Application Platform, le serveur d’applications ‘scale-out’ de nouvelle génération qui inclue maintenant la capacité de déployer un war et de bénéficier immédiatement des atouts de GigaSpaces.

      Il est très intéressant de voir comment GigaSpaces a évolué d’un « marché de niche » orienté hautes performances, latence faible et scalabilité horizontale pour se lancer à la conquête des grands espaces dans le monde du Serveur d’Applications, de la Virtualisation Applicative et du Cloud Computing.
      Originellement, GigaSpaces embarque dans son implémentation un certain nombre de services de la spécification JINI dont la plate-forme tire sa force.
      Il y a quelques années GigaSpaces a fait le bon choix de mon point de vue en se « mariant » au framework Spring afin de fournir le niveau d’abstraction suffisant pour éviter le « vendor lock-in » et faciliter la réutilisation de code existant (entre autres).
      Ils ont ensuite fait évoluer la plate-forme afin de ne pas fournir une plate-forme uniquement dédiée à la communauté Java mais en prenant en compte les besoins des communautés .Net et C++.

      La convergence des visions technologiques sur le développement d’applications d’entreprises modulaires et scalables de sociétés telles que GigaSpaces et SpringSource (et d’autres), me semblent être un signe d’une évolution du modèle traditionnel de développement d’applications.
      La tendance est clairement à l’utilisation de plates-formes souples, non intrusives, légères, intégrables facilement dans des Usines Logicielles et fournissant un ensemble de services et d’implémentations de bonnes pratiques d’architecture afin de nous permettre de nous concentrer sur la logique métier et pas uniquement dans le domaine des applications Web.

      Adaptées au modèle technique et économique (‘Infrastructure à la demande’) proposé par les vendeurs de Cloud Computing tels qu’Amazon (EC2) elles permettent le développement d’applications extensibles adaptables à la charge et dont le coût opérationnel correspond à l’utilisation effective des ressources.

      Nous sommes dans l’ère de l’application élastique !
      C’est Mr Fantastic qui va être content ;-)

      L’intérêt pour un responsable IT est que ce type d’approche permet d’adresser des besoins de scalabilité applicative en réduisant les coûts de développement, d’intégration et opérationnels, et, cerise sur le gâteau, est bénéfique pour l’environnement par son intégration naturelle dans des environnement virtualisés.

      J’espère vous voir lors de cet événement.

      Plus d’infos sur GigaSpaces en allant sur le blog de Nati Shalom (CTO GigaSpaces) ou directement sur le site Web de GigaSpaces.

      Compute Grid – Parallel Processing new generation

      GridGain introduced some years ago the neat capacity to execute remotely some Java code without any deployment in a MapReduce style. New GigaSpaces 6.6 release introduces a similar feature.

      How do they compare? Are they equally powerful? To try answering this question we will develop on both platforms a simple application summing characters of some words.

      API

      A similar high level interface allows to execute multiple times a task then reduce all results in a final answer. In GigaSpace this interface is Task, in GridGain GridTask.

      While similar in appearance their usage is quite different.

      In GridGain a task will be split in several Jobs server side with full control on those individual Jobs. This includes arguments but also job types. Each individual job execution can then be split into sub jobs

      In GigaSpaces a task will be executed on some (or all) nodes but identically. You cannot split and generate dynamically parameterized tasks. This can be simulated using ExecutorBuilder but client side. In our case we will have to manually reduce client side our results. Tasks executions are here intended to be parallelized on a set of partitions then reduced thus limiting dynamic behaviors.

      Both products allow to control what to do with incoming results during reduce phase and when to stop and return final result.

      GigaSpaces

      Our sample implementation would be here divided into two pieces.

      The task itself:

      import org.openspaces.core.executor.Task;
      
      public class GridWordCountTask implements Task {
        private static final long serialVersionUID = 1L;
        private final String word;
      
        public GridWordCountTask(final String word) {
          this.word = word;
        }
      
        public Integer execute() throws Exception {
          return this.word.length();
        }
      
      }
      

      and the client side code:

      final IJSpace proxy = IJSpace.class.cast(SpaceFinder.find(args[0]));
      final GigaSpace gigaSpace = new GigaSpaceConfigurer(proxy).gigaSpace();
      final ExecutorBuilder executorBuilder = gigaSpace.executorBuilder(new SumReducer(Integer.class));
      final String sentence = "This is a very simple test.";
      
      for (final String word : sentence.split(" ")) {
        executorBuilder.add(new GridWordCountTask(word), 0);
      }
      

      Pros:

      • Native support with GigaSpace component.
      • Resources defined in your Processing Unit server side.
      • Built in reducers.

      Cons:

      • Classes definition modification implies space restart. This is currently a known limitation GigaSpaces R&D will overcome in a further release.
      • Routing execution has to be manually handled.
      • Multiple concurrent executions are strictly identical. You can’t provide different arguments (you have to retrieve arguments as part of the logic -through the space for instance-).

      GridGain

      Here is the task implementation:

      public class GridWordCountTask extends GridTaskSplitAdapter {
      
        private static final long serialVersionUID = 1L;
      
        @Override
        protected Collection split(final int gridSize, final String argument) throws GridException {
          final List jobs = new ArrayList(1);
          for (final String word : argument.split(" ")) {
            jobs.add(new GridJobAdapter(argument) {
      
              private static final long serialVersionUID = 1L;
      
              public Integer execute() {
                return word.length();
              }
      
            });
      
          }
          return jobs;
        }
      
        public Integer reduce(final List results) throws GridException {
          int sum = 0;
          for (final GridJobResult result : results) {
            sum += (Integer) result.getData();
          }
          return sum;
        }
      
      }
      

      and the client code:

      GridFactory.start();
      try {
        final String sentence = "This is a very simple test.";
      
        final GridTaskFuture future = GridFactory.getGrid().execute(GridWordCountTask.class, sentence);
        System.out.println("Sentence <"+sentence+"> has <"+future.get()+"> characters.");
      } finally {
        GridFactory.stop(true);
      }
      

      Pros:

      • Annotation facility based on AOP (Gridify).
      • Easily extensible/pluggable to a number of products.
      • Good documentation/samples.
      • Progress indicators of tasks/jobs can be generated.

      Cons:

      • No user interface.

      ExecutorService support

      Both products support ExecutorService to execute tasks. This almost remove the vendor specific code and facilitate switching between local and remote execution (might be useful for testing).

      The only mandatory step is to ensure that your Callable is Serializable. Relying on following interface will do the job:

      public interface GridCallable<E extends Serializable> extends Callable<E>, Serializable {
      }
      

      Conclusion

      While still young GigaSpaces native support of remote java code is a good news and will certainly become a killer feature. Integrated approach advocated by GigaSpaces allows to really easily submit task execution which can natively using the simple Space API access in memory information. Furthermore data affinity is a key feature here and doesn’t have to be managed.
      On the other hand GridGain focuses on task executions and allows to plug a number of components (including caching component) through their nice SPI support. Remote execution is more mature and supports concepts such as job stealing and pluggable load balancing.

      For now GridGain specialized framework allows more complex remote execution work flows but introduction of this new Executor feature gives us a sign that GigaSpaces is willing to fill the gap sooner than later.
      GigaSpaces integrated (by design) approach (in memory caching, virtual ESB, parallel processing and transactional support) is definitively worth a look if you privilege ease of use and management or are looking for very low latency application platform providing capabilities you may have to incorporate into your application by linking several pieces of technology together.

      Resources

      Enhanced GigaSpaces Maven integration

      Latest GigaSpaces release (6.5) comes with an integrated Maven facility. This support is provided through 2 functionnalities:

      • a script and associated set of poms to install GS jars in your local repository
      • a plugin providing hability to create a pu based on a templte, start a local pu container and deploy pu to a running GSM

      This is a great news for the GS users’ community and confirm that Maven becomes an entreprise player. Unfortunately this plugin does not really fit into Maven architecture and way of thinking. Prior to Maven support in GS product we developed internally a number of plugins whose functionalities are similar but (in my purist opinion) more Maven friendly.

      Leverage Packaging type

      Maven packaging allows to choose how your project will be packaged. maven-pu-plugin allows to use a pu packaging which will -what a surprise!- generate a pu instead of a regular jar.

      Cargo as a de facto container abstraction standard

      Cargo framework supports a good variety of container and facilitates their manipulation through a common API from Java, ant and maven. cargo-container-openspaces provides OpenSpaces container to cargo (currenlty only standalone container).

      How does it help?

      The difference between those plugins and GS relatives is not only about clean integration. This tight integration with maven simplifies deployment as pu is a first class citizen.
      Furthermore Cargo plugin fully supports pu packaging type which makes integration tests as part of the lifecycle of your project feasible.

      See following project for a sample on how to use both plugins.

      Single mirror multiple data-sources

      As part of my job, I often visit customers of very different needs and application types, but most of them have one thing in common; data, data and more data. Data related challenges are numerous but in this post I’d like to share with you a few alternatives to solving a common scenario; where the application is using multiple persistency layers that need to be synchronized, without compromising consistency or performance.

      Persistency as a Service

      Data modification performed on a GigaSpaces cluster can be received asynchronously using a central process. This process is called the Mirror Service.

      This concept is mostly used in two scenarios:

      • As a persistence mechanism; click here to read more.
      • As an optimized over the WAN replication facility

      The Mirror Service allows providing your own logic to deal with batches of modifications by implementing the BulkDataPersister interface. While a powerful capability, this does not allow configuring multiple implementations simultaneously.

      Simultaneous Configuration

      A solution to workaround the challenge stated above is to implement a specific BulkDataPersister that broadcasts the data to concrete implementations, internally. Every method calls will then be forwarded to all persistency layers. Composite BulkDataPersister is a generic implementation of this pattern, allowing to simply configure multiple concrete BulkDataPersister used by a Mirror Service.

      What do I mean by simply? All you need to do is to configure your regular BulkDataPersister implementations (using either regular property file or spring injection) and then configure the Mirror Service to use Composite BulkDataPersister.

      Internally, a thread pool will be used to delegate the execution of all implementations in parallel.

      Inconsistency Handling

      The Composite BulkDataPersister approach could leads to inconsistency between the various BulkDataPersisters, in case one of the delegates fails.

      To solve this, the following steps can be taken:

      • A generic strategy can be used for handling partial failures.

      • One of the default strategies will use another space to store all information related to a particular failure.

      • Ultimately, if the strategy itself fails, an exception is propagated to the Mirror Service, which then triggers the redo-log mechanism (so one batch might be received several time by a delegate).

      Implementation of this pattern with full documentation is available here.

      Since inconsistencies pose a potential risk using this approach, I recommend keeping in mind all failure scenarios, including the most unlikely ones. If everything fails, data modifications can be received several times by persistency layers due to the Mirror Service redo-log granularity.

      Nevertheless, this simple pattern allows leveraging the performance improvement provided by the Mirror Service in highly distributed and dispersed environments, while still ensuring full reliability. In fact, one of our clients with strong WAN performance requirements is already using it.

      Further improvements to this pattern might include transaction usage and JMX management.

      Do you consider those features important? Are the available entry points sufficient to your needs?