On Monday, August 12, 2013 5:26:19 PM UTC-4, Matthew Pitts wrote:
>
> On Friday, May 31, 2013 10:50:21 AM UTC-4, Yan wrote:
>>
>> Hi there,
>>
>> I have a Parent object containing a list of Children objects. Both are
>> EntityProxy. My RequestFactory API is to persist the Parent along with
>> Children collection. My JPA layer is EclipseLink (JPA 1.0), with entity
>> manager cache ENABLED.
>>
>> In UI, I change some property on children (without changing parent). When
>> the backend API is called, I expect to see that the Parent's children
>> objects will have the updates.
>>
>> In GWT 2.4.0, I do see that because GWT 2.4.0 sends the list of children
>> to server regardless. In GWT 2.5.1, I see only the delta is sent across
>> the wire (this is correct), but in the backend, I do not see the children
>> collection with updates, that is incorrect.
>>
>> I did implement one-entitymanager-per-request pattern based on a solution
>> someone offered on this group. I verified that only one instance of child
>> is created by JPA during the request. I also verified that GWT client is
>> correctly sending the delta to GWT server and setter methods are called on
>> JPA entity to set the correct value (after JPA loads children from
>> database). Afterwards, the setter is not called and no child object ever
>> created again.
>>
>> However, when the code reaches the API (as seen in debugger), I do not
>> see the children objects has the updates.
>>
>> Why is this? GWT runtime is somehow loading the object from somewhere
>> else?
>>
>> Thanks,
>> Yan
>>
>
> I believe I am having this same problem after upgrading to 2.5.1 and I
> would really appreciate some help with it. Here's some of the behavior I've
> seen:
>
> - changes made to existing child entities retrieved via .with("...") do
> not get persisted server-side when saving the parent entity
> - new child entities created and added to the collection within the
> parent do get persisted server-side when saving the parent entity
> - if a new child entities are created and added to the collection *and*
> changes are made to an existing child entity, then both the new and
> existing entity changes are persisted when saving the parent entity
> - deleting a child from the collection and saving the parent results in
> the corresponding server-side child object being deleted (when JPA
> orphanRemoval = true is used)
> - the above behavior has been observed on 2 different Proxy/Entity/Locator
>
> I'll see if it's practical to put together a standalone project to
> duplicate the behavior. For now here is my architecture...
>
> - JPA-based (with some Eclipselink-specific annotations sprinkled in) POJO
> entity hierarchy
> - EJB3 layer using injected EntityManager instances for persistence
> operations (I've experimented with a mixture of @Stateless vs @Stateful but
> see no difference in behavior)
> - Custom EntityServiceLocator used as 'locator' designation in all
> @Service annotations (provides static util methods to lookup EJBs via JNDI)
> - per-Proxy-type Locator setup
> - all running as web/ejb projects from monolithic ear in Glassfish 3.1
> with EclipseLink 2.4.1
>
> I've done some work to try and ensure I'm getting the
> EntityManager-per-request behavior I've read is necessary for RF to work
> properly, but I'm not confident I have it working.
>
> Since I'm not sure of the intricacies of how RF uses Locators and how best
> to make them interact with EJBs I'm sure some of my architecture is
> non-optimal. But it was working quite well with GWT 2.4.
>
> Any guidance in troubleshooting this is greatly appreciated.
>
> Regards,
> -matt
>
After working on the OSIV semantics I was able to get changes in child
proxies to successfully persist server-side.
I ended up:
1) Converting all relevant EJBs to Stateful.
2) Implementing 'extended persistence context' using another Stateful EJB
just for providing an EntityManager that's injected into all my other
Stateful EJBs
3) Creating a custom EJB JNDI lookup util class used by GWT locators to get
EJBs and cache them into the current request context via
RequestFactoryServlet.getThreadLocalRequest().setAttribute(...). This
ensures that during any given RF request all interaction with a given bean
is performed against the same instance of that bean.
Please feel free to share feedback on this. I may create a new top-level
post with more details.
--
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.
