Re: Request order
Stefan, Did you read this post? http://groups.google.com/group/google-web-toolkit/browse_thread/thread/6d982ecf9398ddec Queueing your requests in the client guarantees server side execution order, albeit it might be a bit drastic. Is your locking/check mechanism generic? Kristof On Nov 21, 2:44 pm, Stefan Bachert wrote: > Hi Jeff, > > > Here's what > > I'm still not sure of: are you looking to undo/redo at the attribute level, > > the entity level, transaction (multiple entities) level? > > I do no more looking for undo/redo, I solved it at the latter level. > > However, the reason for this thread was that I figured out, that > nothing guaranties, that servlet requests are executed in the same > order as they are send from browser. > Meanwhile I did some locking/check to enforce the order. > I had hoped that someone knows an easy solution, may be some > configuration entry. However, topic solved. > > Stefan Bacherthttp://gwtworld.de > > On 20 Nov., 16:22, Jeff Chimene wrote: > > > > > > > > > Hi Stefan: > > > Perhaps we need a better functional requirement? > > > From what I can tell, there is a requirement for transaction semantics; it's > > difficult to eliminate this requirement based on the conversation so far (In > > this thread you introduced the concept of interacting servers). Here's what > > I'm still not sure of: are you looking to undo/redo at the attribute level, > > the entity level, transaction (multiple entities) level? > > > Perhaps there's some Java server-side technology that you can employ? > > > On Sat, Nov 20, 2010 at 7:20 AM, Stefan Bachert > > wrote: > > > > Hi, > > > > I had a look at gwt-dispatch. > > > > I do not see any logic which is able to avoid to execute requests on > > > the server side in an other order than the client sends it. > > > This situation may happens rarely but it is not impossible. > > > > An example. > > > > Client send three requests A,B,C. > > > > Servlet-Thread x getrequestA but stops/waits/slowdown for some > > > reason very early, may be in the dispatcher itself. > > > > An other thread y getrequestB and thread z getrequestC. > > >RequestC may completes first, before B completes, before C completes. > > > (Not likely, but not impossible) > > > (Consider running a container on two cpus, too!) > > > > gwt-dispatch lacks other problems. It produces too much communication > > > and latency. When the server is working with transactions, any action > > > will require one transaction, which slows down the server performance, > > > too. > > > So gwt-dispatch is not a good choice for a high performance systems. > > > > Stefan Bachert > > >http://gwtworld.de > > > > On 19 Nov., 14:56, ep wrote: > > > > actually, its concern of a client to chain the requests, as only it > > > > knows in which order the requests are initiated. actually, your user > > > > shall not be available to execute instructions in parallel, so your > > > > button has to be disabled until previous calculation (server response) > > > > has been returned. > > > > > again, you may want to have a look at gwt-dispatch project. they > > > > implement Command Pattern with easy undo support, and chaining. the > > > > latter would help if you dont want to disable your button whilst > > > > processing results, so the requests are just queued in order they are > > > > requested and processed sequentially, each based on the result from > > > > the other... > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to google-web-tool...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-web-toolkit+unsubscr...@googlegroups.com > > cr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
well, actually, there is. you could subclass remoteServiceServlet and implement the marker interface SingleThreadModel (servlet API), then your container ensures to process only one request at a time by that servlet instance. yet, no one prevents client from sending request B before A even though you instructed so in your code. this is your business case - create a chain on the client to execute "dispatched" requests in sequential order On 21 Nov., 14:44, Stefan Bachert wrote: > Hi Jeff, > > > Here's what > > I'm still not sure of: are you looking to undo/redo at the attribute level, > > the entity level, transaction (multiple entities) level? > > I do no more looking for undo/redo, I solved it at the latter level. > > However, the reason for this thread was that I figured out, that > nothing guaranties, that servlet requests are executed in the same > order as they are send from browser. > Meanwhile I did some locking/check to enforce the order. > I had hoped that someone knows an easy solution, may be some > configuration entry. However, topic solved. > > Stefan Bacherthttp://gwtworld.de > > On 20 Nov., 16:22, Jeff Chimene wrote: > > > > > > > > > Hi Stefan: > > > Perhaps we need a better functional requirement? > > > From what I can tell, there is a requirement for transaction semantics; it's > > difficult to eliminate this requirement based on the conversation so far (In > > this thread you introduced the concept of interacting servers). Here's what > > I'm still not sure of: are you looking to undo/redo at the attribute level, > > the entity level, transaction (multiple entities) level? > > > Perhaps there's some Java server-side technology that you can employ? > > > On Sat, Nov 20, 2010 at 7:20 AM, Stefan Bachert > > wrote: > > > > Hi, > > > > I had a look at gwt-dispatch. > > > > I do not see any logic which is able to avoid to execute requests on > > > the server side in an other order than the client sends it. > > > This situation may happens rarely but it is not impossible. > > > > An example. > > > > Client send three requests A,B,C. > > > > Servlet-Thread x get request A but stops/waits/slowdown for some > > > reason very early, may be in the dispatcher itself. > > > > An other thread y get request B and thread z get request C. > > > Request C may completes first, before B completes, before C completes. > > > (Not likely, but not impossible) > > > (Consider running a container on two cpus, too!) > > > > gwt-dispatch lacks other problems. It produces too much communication > > > and latency. When the server is working with transactions, any action > > > will require one transaction, which slows down the server performance, > > > too. > > > So gwt-dispatch is not a good choice for a high performance systems. > > > > Stefan Bachert > > >http://gwtworld.de > > > > On 19 Nov., 14:56, ep wrote: > > > > actually, its concern of a client to chain the requests, as only it > > > > knows in which order the requests are initiated. actually, your user > > > > shall not be available to execute instructions in parallel, so your > > > > button has to be disabled until previous calculation (server response) > > > > has been returned. > > > > > again, you may want to have a look at gwt-dispatch project. they > > > > implement Command Pattern with easy undo support, and chaining. the > > > > latter would help if you dont want to disable your button whilst > > > > processing results, so the requests are just queued in order they are > > > > requested and processed sequentially, each based on the result from > > > > the other... > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to google-web-tool...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-web-toolkit+unsubscr...@googlegroups.com > > cr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi Jeff, > Here's what > I'm still not sure of: are you looking to undo/redo at the attribute level, > the entity level, transaction (multiple entities) level? I do no more looking for undo/redo, I solved it at the latter level. However, the reason for this thread was that I figured out, that nothing guaranties, that servlet requests are executed in the same order as they are send from browser. Meanwhile I did some locking/check to enforce the order. I had hoped that someone knows an easy solution, may be some configuration entry. However, topic solved. Stefan Bachert http://gwtworld.de On 20 Nov., 16:22, Jeff Chimene wrote: > Hi Stefan: > > Perhaps we need a better functional requirement? > > From what I can tell, there is a requirement for transaction semantics; it's > difficult to eliminate this requirement based on the conversation so far (In > this thread you introduced the concept of interacting servers). Here's what > I'm still not sure of: are you looking to undo/redo at the attribute level, > the entity level, transaction (multiple entities) level? > > Perhaps there's some Java server-side technology that you can employ? > > On Sat, Nov 20, 2010 at 7:20 AM, Stefan Bachert wrote: > > > Hi, > > > I had a look at gwt-dispatch. > > > I do not see any logic which is able to avoid to execute requests on > > the server side in an other order than the client sends it. > > This situation may happens rarely but it is not impossible. > > > An example. > > > Client send three requests A,B,C. > > > Servlet-Thread x get request A but stops/waits/slowdown for some > > reason very early, may be in the dispatcher itself. > > > An other thread y get request B and thread z get request C. > > Request C may completes first, before B completes, before C completes. > > (Not likely, but not impossible) > > (Consider running a container on two cpus, too!) > > > gwt-dispatch lacks other problems. It produces too much communication > > and latency. When the server is working with transactions, any action > > will require one transaction, which slows down the server performance, > > too. > > So gwt-dispatch is not a good choice for a high performance systems. > > > Stefan Bachert > >http://gwtworld.de > > > On 19 Nov., 14:56, ep wrote: > > > actually, its concern of a client to chain the requests, as only it > > > knows in which order the requests are initiated. actually, your user > > > shall not be available to execute instructions in parallel, so your > > > button has to be disabled until previous calculation (server response) > > > has been returned. > > > > again, you may want to have a look at gwt-dispatch project. they > > > implement Command Pattern with easy undo support, and chaining. the > > > latter would help if you dont want to disable your button whilst > > > processing results, so the requests are just queued in order they are > > > requested and processed sequentially, each based on the result from > > > the other... > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to google-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi Stefan: Perhaps we need a better functional requirement? >From what I can tell, there is a requirement for transaction semantics; it's difficult to eliminate this requirement based on the conversation so far (In this thread you introduced the concept of interacting servers). Here's what I'm still not sure of: are you looking to undo/redo at the attribute level, the entity level, transaction (multiple entities) level? Perhaps there's some Java server-side technology that you can employ? On Sat, Nov 20, 2010 at 7:20 AM, Stefan Bachert wrote: > Hi, > > I had a look at gwt-dispatch. > > I do not see any logic which is able to avoid to execute requests on > the server side in an other order than the client sends it. > This situation may happens rarely but it is not impossible. > > An example. > > Client send three requests A,B,C. > > Servlet-Thread x get request A but stops/waits/slowdown for some > reason very early, may be in the dispatcher itself. > > An other thread y get request B and thread z get request C. > Request C may completes first, before B completes, before C completes. > (Not likely, but not impossible) > (Consider running a container on two cpus, too!) > > gwt-dispatch lacks other problems. It produces too much communication > and latency. When the server is working with transactions, any action > will require one transaction, which slows down the server performance, > too. > So gwt-dispatch is not a good choice for a high performance systems. > > Stefan Bachert > http://gwtworld.de > > On 19 Nov., 14:56, ep wrote: > > actually, its concern of a client to chain the requests, as only it > > knows in which order the requests are initiated. actually, your user > > shall not be available to execute instructions in parallel, so your > > button has to be disabled until previous calculation (server response) > > has been returned. > > > > again, you may want to have a look at gwt-dispatch project. they > > implement Command Pattern with easy undo support, and chaining. the > > latter would help if you dont want to disable your button whilst > > processing results, so the requests are just queued in order they are > > requested and processed sequentially, each based on the result from > > the other... > > > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Running A, B & C in parallel would imply that there are no dependencies between them. On the other hand if there are dependencies between them such as C is dependend upon B and B is dependent upon A then the solution is to chain B to run when the async call back for A returns success; similarly, only run C when the async call back for B returns success. Generalized RPC implementations have no understanding of the semantics of your business rules, they are merely an API. It is up to the developer to use the API to model their business rules so when server processes can run in parallel with each other the API can support that and when they need to run serially due to some dependencies between them the API can support that as well. GWT's RPC implementation adequately supports both models IMO. Jeff On Sat, Nov 20, 2010 at 9:20 AM, Stefan Bachert wrote: > Hi, > > I had a look at gwt-dispatch. > > I do not see any logic which is able to avoid to execute requests on > the server side in an other order than the client sends it. > This situation may happens rarely but it is not impossible. > > An example. > > Client send three requests A,B,C. > > Servlet-Thread x get request A but stops/waits/slowdown for some > reason very early, may be in the dispatcher itself. > > An other thread y get request B and thread z get request C. > Request C may completes first, before B completes, before C completes. > (Not likely, but not impossible) > (Consider running a container on two cpus, too!) > > gwt-dispatch lacks other problems. It produces too much communication > and latency. When the server is working with transactions, any action > will require one transaction, which slows down the server performance, > too. > So gwt-dispatch is not a good choice for a high performance systems. > > Stefan Bachert > http://gwtworld.de > > On 19 Nov., 14:56, ep wrote: > > actually, its concern of a client to chain the requests, as only it > > knows in which order the requests are initiated. actually, your user > > shall not be available to execute instructions in parallel, so your > > button has to be disabled until previous calculation (server response) > > has been returned. > > > > again, you may want to have a look at gwt-dispatch project. they > > implement Command Pattern with easy undo support, and chaining. the > > latter would help if you dont want to disable your button whilst > > processing results, so the requests are just queued in order they are > > requested and processed sequentially, each based on the result from > > the other... > > > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- *Jeff Schwartz* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi, I had a look at gwt-dispatch. I do not see any logic which is able to avoid to execute requests on the server side in an other order than the client sends it. This situation may happens rarely but it is not impossible. An example. Client send three requests A,B,C. Servlet-Thread x get request A but stops/waits/slowdown for some reason very early, may be in the dispatcher itself. An other thread y get request B and thread z get request C. Request C may completes first, before B completes, before C completes. (Not likely, but not impossible) (Consider running a container on two cpus, too!) gwt-dispatch lacks other problems. It produces too much communication and latency. When the server is working with transactions, any action will require one transaction, which slows down the server performance, too. So gwt-dispatch is not a good choice for a high performance systems. Stefan Bachert http://gwtworld.de On 19 Nov., 14:56, ep wrote: > actually, its concern of a client to chain the requests, as only it > knows in which order the requests are initiated. actually, your user > shall not be available to execute instructions in parallel, so your > button has to be disabled until previous calculation (server response) > has been returned. > > again, you may want to have a look at gwt-dispatch project. they > implement Command Pattern with easy undo support, and chaining. the > latter would help if you dont want to disable your button whilst > processing results, so the requests are just queued in order they are > requested and processed sequentially, each based on the result from > the other... > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
actually, its concern of a client to chain the requests, as only it knows in which order the requests are initiated. actually, your user shall not be available to execute instructions in parallel, so your button has to be disabled until previous calculation (server response) has been returned. again, you may want to have a look at gwt-dispatch project. they implement Command Pattern with easy undo support, and chaining. the latter would help if you dont want to disable your button whilst processing results, so the requests are just queued in order they are requested and processed sequentially, each based on the result from the other... On 19 Nov., 14:36, Stefan Bachert wrote: > Hi, > > for me undo is just a replay of the transitions in the opposite order. > So in this context "replay" is just the direction independant term of > undo/redo. > > Using a key logger is an other kind of "replay" which is not my case. > > Any transition runs in a transaction. > > SN alone is not sufficient. Consider the user clicks 2 buttons > quickly. > button a = method which add a number, say 4 > button b = method which multiply a number, say 4. > > The order must preserved because the result depends on it. > a,b : 0 + 4 = 4; 4*4 = 16; > b,a : 0 * 4 = 0; 0 + 4 = 4; > > You could only hold undo/redo state in client in very simple cases. > In common only the server side has enough access to the needed data. > In addition security aspects forces the undo/redo sequence to be on > the server side, > > Meanwhile I send an SN with any request and force the order the > request. > (Still wondering what will happen when the app needs to run on > multiple servers, OK, not a GWT topic) > > Stefan Bacherthttp://gwtworld.de > > On 18 Nov., 17:34, Jeff Chimene wrote: > > > On Thu, Nov 18, 2010 at 9:18 AM, Stefan Bachert > > wrote: > > > > Hi, > > > > I am doing undo/redo. Therefore it is mandatory to handle all requests > > > on the server in the same order to be able to replay it > > > There are two issues here: > > > undo/redo > > replay > > > They are different. > > > Setting aside transaction semantics (commit/rollback) since you're probably > > not interested in implementing that, undo/redo can be performed by attaching > > a sequence number per write to the server, keeping that SN in undo/redo > > stacks on the client, manipulating the stacks as appropriate. > > > replay requires a keystroke logger. > > > Do you really need to interact with the server for such a feature? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi, for me undo is just a replay of the transitions in the opposite order. So in this context "replay" is just the direction independant term of undo/redo. Using a key logger is an other kind of "replay" which is not my case. Any transition runs in a transaction. SN alone is not sufficient. Consider the user clicks 2 buttons quickly. button a = method which add a number, say 4 button b = method which multiply a number, say 4. The order must preserved because the result depends on it. a,b : 0 + 4 = 4; 4*4 = 16; b,a : 0 * 4 = 0; 0 + 4 = 4; You could only hold undo/redo state in client in very simple cases. In common only the server side has enough access to the needed data. In addition security aspects forces the undo/redo sequence to be on the server side, Meanwhile I send an SN with any request and force the order the request. (Still wondering what will happen when the app needs to run on multiple servers, OK, not a GWT topic) Stefan Bachert http://gwtworld.de On 18 Nov., 17:34, Jeff Chimene wrote: > On Thu, Nov 18, 2010 at 9:18 AM, Stefan Bachert wrote: > > > Hi, > > > I am doing undo/redo. Therefore it is mandatory to handle all requests > > on the server in the same order to be able to replay it > > There are two issues here: > > undo/redo > replay > > They are different. > > Setting aside transaction semantics (commit/rollback) since you're probably > not interested in implementing that, undo/redo can be performed by attaching > a sequence number per write to the server, keeping that SN in undo/redo > stacks on the client, manipulating the stacks as appropriate. > > replay requires a keystroke logger. > > Do you really need to interact with the server for such a feature? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
On Thu, Nov 18, 2010 at 9:18 AM, Stefan Bachert wrote: > Hi, > > I am doing undo/redo. Therefore it is mandatory to handle all requests > on the server in the same order to be able to replay it There are two issues here: undo/redo replay They are different. Setting aside transaction semantics (commit/rollback) since you're probably not interested in implementing that, undo/redo can be performed by attaching a sequence number per write to the server, keeping that SN in undo/redo stacks on the client, manipulating the stacks as appropriate. replay requires a keystroke logger. Do you really need to interact with the server for such a feature? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi, > batch them (the requests) from client and push them in same http > request :) Allready done, however, this is a little optimization but no solution. It does not disable a user to click 4 times on the same button. After the first one I don't have any idea whether 3 other clicks will follow or not. When there is no easy feature to support this, than the easiest thing is to number any requests from client and execute them only in order. (Maybe be "abused" as attack detection, too) Stefan Bachert http://gwtworld.de On 17 Nov., 11:09, ep wrote: > batch them (the requests) from client and push them in same http > request :) > > do you need them to execute also in the same order? meaning serially? > so that requests actually cannot be processed in parallel anymore? > then you may want to look at gwt-dispatch project, they recently have > added support to queue the requests. > > otherwise you could queue the requests manually on the client and > execute them one after another... but Jeff already asked a right > question > > On 17 Nov., 12:07, Stefan Bachert wrote: > > > Hi, > > > I need to get any requests from my browser client in the same order on > > the server side. > > > implementing SingleThreadModel would not solve this requirement. > > synchronizing HttpSession may fail on 3 or more requests. > > > Any ideas how to achive this? > > > Stefan Bacherthttp://gwtworld.de -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi, I am doing undo/redo. Therefore it is mandatory to handle all requests on the server in the same order to be able to replay it. Stefan Bachert http://gwtworld.de On 17 Nov., 10:37, Jeff Chimene wrote: > Hi Stefan: > > What problem are you trying to solve? > > On Wed, Nov 17, 2010 at 4:07 AM, Stefan Bachert wrote: > > > Hi, > > > I need to get any requests from my browser client in the same order on > > the server side. > > > implementing SingleThreadModel would not solve this requirement. > > synchronizing HttpSession may fail on 3 or more requests. > > > Any ideas how to achive this? > > > Stefan Bachert > >http://gwtworld.de > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to google-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
batch them (the requests) from client and push them in same http request :) do you need them to execute also in the same order? meaning serially? so that requests actually cannot be processed in parallel anymore? then you may want to look at gwt-dispatch project, they recently have added support to queue the requests. otherwise you could queue the requests manually on the client and execute them one after another... but Jeff already asked a right question On 17 Nov., 12:07, Stefan Bachert wrote: > Hi, > > I need to get any requests from my browser client in the same order on > the server side. > > implementing SingleThreadModel would not solve this requirement. > synchronizing HttpSession may fail on 3 or more requests. > > Any ideas how to achive this? > > Stefan Bacherthttp://gwtworld.de -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request order
Hi Stefan: What problem are you trying to solve? On Wed, Nov 17, 2010 at 4:07 AM, Stefan Bachert wrote: > Hi, > > I need to get any requests from my browser client in the same order on > the server side. > > implementing SingleThreadModel would not solve this requirement. > synchronizing HttpSession may fail on 3 or more requests. > > Any ideas how to achive this? > > Stefan Bachert > http://gwtworld.de > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
