Hi Umit, Thanks for those thoughts. I failed to mention our use of with() in this area. When we read the graph from the server, we do in fact make use of with() with an extensive list of Strings to force the EntityProxy graph population as we need.
Interestingly, when we make the call back to the server from client code to persist end user edits, we do NOT use with(). I can experiment with that to see if providing a reduced list of Strings with with() provides any relief. That is an interesting thought. I personally dislike the fact that I have to specify with() at all, when my EntityProxy declarations already indicate which properties I expect to be in existence on the client side. With our graph being so deep, a Domain Model refactoring causes an undesirable ripple through those Strings. Providing another list of Strings for the write based path would add to my discomfort. However, I will do some experimenting to see if that can provide any relief. Thanks, Doug On Monday, November 4, 2013 11:50:46 PM UTC-8, Ümit Seren wrote: > > @Doug: Sorry I missed the part in your first post where you mentioned that > you already return true in the isLive method. > > RequestFactory uses reflection on the server-side which might be an issue > with a huge graph (although I believe it uses caches to speed up things in > subsequent calls. > I guess you pass the entire graph in the with() call when you retrieve > the instance A. > If you don’t need to change anything in the sub-nodes (B,C,Ex) you could > leave out the with() call for the write action. > Or alternatively you could create additional EntityProxys that contain > only a subset of the sub-nodes. > > > On Tue, Nov 5, 2013 at 3:13 AM, Doug Gschwind > <doug.g...@gmail.com<javascript:> > > wrote: > >> Thanks Umit. Indeed we do that too. We have a ServiceLocator supertype >> which all of our concrete ServiceLocator concrete subclasses extend, and >> isLive() is implemented to unconditionally return true in that >> implementation. >> >> Thanks, >> >> Doug >> >> >> On Monday, November 4, 2013 1:31:28 AM UTC-8, Ümit Seren wrote: >>> >>> If you don’t care about EntityChangeEvents you can also override the >>> isLive() method and return true (see >>> here<http://stackoverflow.com/questions/9476341/requestfactory-theory-why-is-locator-find-being-called-so-often> >>> ). >>> This improved performance quite a bit at least in my case. >>> >>> On Friday, November 1, 2013 1:20:14 AM UTC+1, Doug Gschwind wrote: >>> >>> 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 a topic in the >> Google Groups "Google Web Toolkit" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/google-web-toolkit/6ihnfmnuJy8/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> google-web-toolkit+unsubscr...@googlegroups.com <javascript:>. >> To post to this group, send email to >> google-we...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-web-toolkit. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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+unsubscr...@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.
