Both solutions are great. I re-read RequestFactory official documentation, it uses Jessie's solution. Thomas's solution is good to ,but I don't know if there's any side effect.
在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > 在 2012年3月12日星期一UTC+8下午10时07分31秒，Jesse Hutton写道： > > On Mon, Mar 12, 2012 at 4:36 AM, Thomas Broyer <[email protected]> wrote: > > > > On Monday, March 12, 2012 5:39:00 AM UTC+1, Lopakhin wrote: > >> > >> In a common scenario of Web application, we usually populate > >> cellTable,cellList with our data from RequestFactory context's method, > such > >> as findAll(), at this point , we already done the database query that > get > >> all entity ,but RequestFactory dictate that , to prepare with > appropriate > >> manipulating methods , RF has to go over the list again one by one > >> ,resulting in additional n queries whose result set already in the > memory.As > >> I monitored in the console, the overhead is substantial, even with JPA > >> batching present, the performance is still crippled. > >> > >> According to this post in stackoverflow , we surely can override > >> ServiceDecorator,but it seems that we lose the control over what we can > do > >> with this entity. > >> > >> By far I can not think better solution for this, may be go back to GWT > RPC > >> is good idea. > > > > > > You can use a Locator and override its isLive() method (whose default > > implementation calls getId() and then find()) > > > > (IMO, you *should* use a Locator rather than this static-methods > > anti-pattern anyway) > > > > Another way to mitigate this problem is to always use > EntityManager#find() in your Locator since that will return the entity > from the current persistence context without hitting the db if it is > already there. > > Jesse > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/CoZbLmomyRoJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
