Thursday, October 31, 2013

Implementation alternatives to improve GWT RequestFactory read and write based use cases

Hello everyone,

We are using GWT 2.5.1, Hibernate 4.x as a JPA 2.x provider, Oracle database 11g, and RequestFactory for our application. One of the areas of our application is slightly slow at read time and is noticeably slower at write time. The use case in particular is a fairly complex editor where the read part of the puzzle is used to render the complex UI and the write part of the puzzle is used to save end user edits made in this complex editor UI. In this particular use case, we use RequestFactory. In other areas of our application we have some GWT-RPC in use, but we are migrating away from its use in favor of using RequestFactory.

In our RequestFactory use, we use the ServiceLocator pattern and our ServiceLocator's unconditionally return true from isLive(), for background information. We are not using the Editor framework in this area of the application.

We have been working on this set of use cases some time and are quite comfortable with the Domain Model that we have in place, which to simplify looks like the following :

class A
    |
    -- class B
        |
        -- class C
            |
            -- class D
                |
                -- class E
                    |
                    -- class E1
                    |
                    -- class E2
                    |
                    -- class E3

There are OneToMany relationships between the following classes : A -> B, B -> C, C-> D, D-> E, E -> E1, E -> E2, E -> E3, with back pointing ManyToOne relationships throughout. Each of these classes are not transportable, in the RequestFactory sense, so we have an EntityProxy for each class.

When an end user saves their edits, lots of db query traffic can be seen, which appears to be due to hydrating the entire graph of objects and stitching them together. I suspect that we could reduce the system response time of the save/write use case if all of this ServiceLocator find() infrastructure was subverted since once we read/find the A instance, it can be used to apply all edits without a find() call per node in the graph.

Have any of you faced this type of problem and were you able to find an implementation alternative which proved faster by using maybe GWT-JSON or GWT-RPC or some other means?

If you got here, thanks for reading and your replies in advance.

Doug
            

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

No comments:

Post a Comment