App Server preventing multiple "simultaneous" requests from onebrowser session?

[Lord0]

Hi there,

I have a web app running on Oracle's J2EE container OC4J (10.1.2)

One of the webpages uses two pieces of Ajax functionality, call them
"longRunningAjax" process and "shortRunningAjax" process.

longRunningAjax performs a lot of tasks on the db and can take quite a
time to run.

shortRunningAjax gives the user feedback on longRunningAjax by
monitoring the logs etc that longRunningAjax produces.

So the flow *should be*:

1. User starts longRunningAjax
2. User starts shortRunningAjax
3. shortRunningAjax completes and displays to user the current state
of longRunningAjax
4. Repeat 2-3 as required.
5. longRunningAjax completes

What the flow *actually* is:
1. User starts longRunningAjax
2. User starts shortRunningAjax
3. longRunningAjax completes.
4. shortRunningAjax completes (appearing for all the world like it was
blocked by longRunningAjax)

Each of the two piece of Ajax function perfectly when not run
simultaneously.

I read somewhere that some Application Servers have a configuration
setting which prevents multiple "simultaneous" requests from one
browser session. Which would in this case be the Ajax.

Anybody have any ideas or thoughts on this?

Cheers

Lord0

 

[Mark Space]

I read somewhere that some Application Servers have a configuration
setting which prevents multiple "simultaneous" requests from one
browser session. Which would in this case be the Ajax.

SingleThreadModel

Highly deprecated. It's not on by default. Did you configure this
server or are you using a shared host? What does your hosting provider
say about their default configuration?

The other thing you should do is test this locally on your own system.
Does the problem reproduce? If it does, then it's likely you have a
busy-wait or other lock on the short-running-Ajax task, and it's just
plain blocking until the long task complete. That's needs debug and
design on your end.

 

[Lord0]

Thanks for the feed back

 

[Arne Vajhøj]

I have a web app running on Oracle's J2EE container OC4J (10.1.2)

One of the webpages uses two pieces of Ajax functionality, call them
"longRunningAjax" process and "shortRunningAjax" process.

longRunningAjax performs a lot of tasks on the db and can take quite a
time to run.

shortRunningAjax gives the user feedback on longRunningAjax by
monitoring the logs etc that longRunningAjax produces.

So the flow *should be*:

1. User starts longRunningAjax
2. User starts shortRunningAjax
3. shortRunningAjax completes and displays to user the current state
of longRunningAjax
4. Repeat 2-3 as required.
5. longRunningAjax completes

What the flow *actually* is:
1. User starts longRunningAjax
2. User starts shortRunningAjax
3. longRunningAjax completes.
4. shortRunningAjax completes (appearing for all the world like it was
blocked by longRunningAjax)

Each of the two piece of Ajax function perfectly when not run
simultaneously.

I read somewhere that some Application Servers have a configuration
setting which prevents multiple "simultaneous" requests from one
browser session. Which would in this case be the Ajax.

Anybody have any ideas or thoughts on this?

Sounds a lot like there are some kind of synchronization in your code
that causes short to block until long is done.

Try search for use of synchronized keyword.

Arne

 

[Arne Vajhøj]

SingleThreadModel

SingleThreadModel is an interface that can be impelemnted by servlets
that enforces that one instance of the servlet is only processing
one request.

It can be implemented by blocking a second request. But it can
just as well be implemented by creating a second instance.

And even if it were implemented the first way in OC4J then
i seriously doubt it is the cause because most likely then either
short and long will call different servlets or they will be just
go through a standard controller servlet that does not use
SingleThreadModel.

Arne