8 Replies Latest reply on Dec 3, 2012 9:18 AM by rhauch

    Performance using REST API vs using repository directly via Modeshape JCR APIs

    jasdanh

      If I decide to use the REST api to access the repository, should I be concerned about performance versus accessing the repository directly? Is it recommend and production ready ?

       

      Thanks

        • 1. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
          rhauch

          The REST API will certainly be slower than accessing the repository locally via the JCR API -- it's simply a matter of remote always being slower than local. If you have a choice, the JCR API will be easier and faster. But sometimes remote access is required. So yes, using the latest verison of the REST API is perfectly fine and is recommended.

           

          The performance of the RESTful API will also depends on how you use it. For example, reading a subgraph with one GET call (and a depth>1) will be faster than using a single GET for each node in that subgraph.

          • 2. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
            jasdanh

            Thanks for you quick response.  I will just access the repository local directly using JCR API. I'm building a CMS using Primefaces and other neat ideas.

            • 3. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
              jasdanh

              My plan is to expose CRUD via stateless session beans invoking the ModeShape engine (embedded not JNDI) each time as Service Facade.  JSF will then have access to this facade.  So I'm going to access JCR API directly instead of REST.

               

              Is this fine ?

              • 4. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
                rhauch

                My plan is to expose CRUD via stateless session beans invoking the ModeShape engine (embedded not JNDI) each time as Service Facade.

                 

                I'm not sure what you mean by "embedded". What app/web server are you using? You're not talking about starting up a new engine for every client request, are you? Because that would be very inefficient. Instead, you should start up the engine (as a service) and keep that service (and the ModeShape engine) running for the duration of your deployment.

                JSF will then have access to this facade.  So I'm going to access JCR API directly instead of REST.

                 

                Is this fine ?

                 

                Yes, this should work really well. If possible, create a Session to handle each request, even when that request involves accessing or updating multiple nodes.

                • 5. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
                  jasdanh

                  I'm using Glassfish. But don't have good document for setting up JNDI in glassfish.

                   

                  If I create Session to handle each request, this is just like a servlet.  Giving the modeshape document where it states is threadsafe with the exception of writes how will I handle this with the same session handling each request for transient data ?

                   

                  BTW. Thanks for your help, I started using JackRabbit and got frustrated because of the lack of documentation and just recently moved to Modeshape and has much more support for caching etc.

                  • 6. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
                    rhauch

                    If I create Session to handle each request, this is just like a servlet.  Giving the modeshape document where it states is threadsafe with the exception of writes how will I handle this with the same session handling each request for transient data ?

                     

                    If you're reading data, you can reuse the same Session as long as the Session is never used for writing and thus contains no transient changes; it essentially is just a front for the actual workspace content. Again, you can never write data using this shared Session, as the transient data will interfere with the other readers and writers. So even though this is possible, it is non-standard JCR behavior and your application will never work with another JCR implementation (as Session is not required to be threadsafe and most implementations are not threadsafe!). I'd consider creating a new Session for every (servlet) request that you handle, and only consider shared Sessions if performance warrants it. You can even enable ServletCredentials, which you can instantiate and pass to the Repository.login(...) methods.

                     

                    For writing, you definitely want to obtain a Session, make the changes, and the save the session before completing your processing.

                     

                     

                    Thanks for your help, I started using JackRabbit and got frustrated because of the lack of documentation and just recently moved to Modeshape and has much more support for caching etc.

                     

                    Please let us know if you can't find documentation about something. We never can have enough documentation. :-)

                    1 of 1 people found this helpful
                    • 7. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
                      jasdanh

                      In regards to the starting up the engine, you mentioned that I should deploy it as a service.  Can instead, since I'm using ejb 3.1, use a Singleton EJB to store the modeshape engine for the life of the application ?

                      • 8. Re: Performance using REST API vs using repository directly via Modeshape JCR APIs
                        rhauch

                        Sure, you can use any service-like component that lives as long as your application, including a Singleton EJB.

                        1 of 1 people found this helpful