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

I have an update on this thread, sorry for the delay. Upon a much deeper dive into the write side of this issue, there have been found a number of contributing factors that was causing an unnecessarily long end user wait time upon save/write. Most of these have nothing to do with GWT, RequestFa

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

Anyone volunteers to profile the code to have hints about what's slow? IMO, one solution could be to switch to code generation rather than reflection (particularly the AutoBeans), but that's only if reflection is the bottleneck. On Thursday, November 7, 2013 8:50:08 AM UTC+1, Ümit Seren wrote:

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

Well that's weird. you could put a breakpoint in the getter for the sub-references and see if it gets called when you save without with(). On Wed, Nov 6, 2013 at 10:22 PM, Doug Gschwind wrote: > Hi Umit, > > Oh, I like the idea of the wildcarding in those String instances passed to > with(), wou

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

Hi Umit, Oh, I like the idea of the wildcarding in those String instances passed to with(), would help with refactoring efforts if properties change or are moved to other classes in a graph. According to my testing though, I see no difference in results if upon save we do, or do not use, a val

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

The reason why you have to specify the references in `with()` is exactly that sometimey you don't need the entire domain graph on the client. This way you can specify what you really want to have sent over the wire, potentially saving bandwith and improve de-serialization speed. There is an issue

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

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

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

@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 yo

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

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

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

Hi Thomas, Indeed we are. We keep the Hibernate session open for the duration of the HttpRequest following the Open Session In View pattern. Any other ideas? Thanks, Doug On Sunday, November 3, 2013 3:22:35 PM UTC-8, Thomas Broyer wrote: > > The way RequestFactory is designed, you have to use

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

If you don’t care about EntityChangeEvents you can also override the isLive() method and return true (see here ). This improved performance quite a bit at least in my case. On Friday, N

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

The way RequestFactory is designed, you have to use per-request caches to ensure you only ever have one instance of a given entity within the course of the request. Using Hibernate/JPA, that means using a session-per-request (aka open-session-in-view) pattern. Are you already using it? On Frida

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 edit