Hi Sumit, Yes, I did it that way, but I don't lock objects, the error message tells user that data has been changed by someone else and that he should reload, I use optimistic locking.
Many thanks, On 23 juil, 19:38, Sumit Chandel <[email protected]> wrote: > Hi Aymen, > Yes, that exactly what I meant. I'm guessing that by "concurrent update" > problems, your AsyncCallback will probably just issue an error message > saying that the form or data being modified is already in use (pessimistic > concurrency control)? If so, that sounds like a workable solution to me. > > Hope that helps, > -Sumit Chandel > > > > On Thu, Jul 23, 2009 at 4:43 AM, AymenS <[email protected]> wrote: > > > Hi Sumit, > > > Thank you for your reply, > > > You're right it's a bad practice, I implemented the second solution, > > I've had to do some plumbing in GileadRPCServiceExporter to bubble > > another exception, that I defined, whenever a > > "StaleObjectStateException" is detected. And use a custom > > implementation of AsynCallback to handle this type of problems > > (concurrent updates). > > > You meant something like this, is what I've done appropriate ? > > > On 21 juil, 20:27, Sumit Chandel <[email protected]> wrote: > > > Hi AymenS, > > > You could manually enter the class name that you want to serialize to the > > > generated serialization policy file (for example, as part of your build > > > process). You can take a look at the generated serialization file to see > > an > > > example of the format required to add the exception type to the > > > serialization policy (essentially pairs of fully qualified classnames and > > > booleans indicating whether the type can be instantiated). > > > > However, it's important to note that allowing a Hibernate exception to > > > bubble up to the client-side is generally bad practice. Instead, you > > should > > > catch the exception on the server-side and either delegate the exception > > to > > > something specific and friendlier to the GWT client-side that can be used > > to > > > handle the error elegantly on the client or provide some kind of error > > > signaling in the RPC callback between the client and the server. > > > > Hope that helps, > > > -Sumit Chandel > > > > On Fri, Jul 17, 2009 at 8:29 AM, AymenS <[email protected]> wrote: > > > > > What I know in GWT serialization is that only classes that are > > > > mentionned (params, return type) in RPC methods are included in GWT > > > > serialization policy white-list. > > > > > I need to serialize org.hibernate.StaleObjectStateException, which is > > > > thrown, in server-side, when a concurrency access problem happens. > > > > > I added a fake implementation to the source code of my module to > > > > emulate the real one (org.hibernate.StaleObjectStateException). > > > > > To make it serializable I'm obliged to add the clause " throws > > > > StaleObjectStateException " to methods (in service layer) which are > > > > susceptible to throw it at runtime. > > > > > example: > > > > > Customer update(Customer client) throws StaleObjectStateException; > > > > > My question is the following, is there another way to make " > > > > StaleObjectStateException " without polluting service layer with those > > > > " throws StaleObjectStateException " ? > > > > > p.s. : I'm using GWT-SL (GileadRPCServiceExporter) in server side. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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 -~----------~----~----~----~------~----~------~--~---
