[mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 29, 2008 10:51 AM
To: users@wicket.apache.org
Subject: Re: Pagemap null is still locked by blah exception, help!!
why
does wicket have to lock the pagemap
that's right, i am screwed anyway if request takes too long, but from
the
browser user
To: users@wicket.apache.org
Subject: Re: Pagemap null is still locked by blah exception, help!!
why
does wicket have to lock the pagemap
that's right, i am screwed anyway if request takes too long, but from
the
browser user decide to give up current search by click
If 1 page instance can be accessed by multiply threads we suddenly have to
have synchronize blocks all over the place
in our wicket code (especially the response area, rendering)
Also in the request phase where you can alter components and so on. Also
needs to be synched. (add/remove of
arrrg, I've already changed the implementation by using auto refresh, which
isn't that bad either, I can interupt the previous search request. but if i
have saw ur post earlier, i wouldn't go long way to make those changes.
Thanks anyway.
Johan Compagner wrote:
If 1 page instance can be
what you have now is better - doing a search in a different thread -
because it doesnt bogged on servlet contains's threadpool.
-igor
On Jan 30, 2008 9:11 AM, cemeterygate [EMAIL PROTECTED] wrote:
arrrg, I've already changed the implementation by using auto refresh, which
isn't that bad
On Jan 30, 2008 10:00 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
what you have now is better - doing a search in a different thread -
because it doesnt bogged on servlet contains's threadpool.
The only thing to consider is that you might want to limit the number
of threads you can spawn.
I agreed, able to interupt previous request and start a new is nice to have
:) i am pulling per 1 second because some queries actually come back pretty
quick. i hope this is not going to put stress on the server when there are
excessive number of long requests.
Thanks for answering my
yea, i am using a thread pool. thanks
Eelco Hillenius wrote:
On Jan 30, 2008 10:00 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
what you have now is better - doing a search in a different thread -
because it doesnt bogged on servlet contains's threadpool.
The only thing to consider is that
that's right, i am screwed anyway if request takes too long, but from the
browser user decide to give up current search by click the stop button and
fire a new search. Since the pagemap is still locked by previous request,
the second request will have to wait. sounds like i will end up handle
cant we thread.interrupt() ? or will that actually kill the servlet
thread without restarting it? havent throught this through all the
way, just brainstorming.
-igor
On Jan 28, 2008 3:11 PM, Johan Compagner [EMAIL PROTECTED] wrote:
how do you kill a current request?
you can't shoot down the
you can do that polling with an ajax request
and if the searches take that long anyway polling every second doesn't make
sense to me anyway
you can do that every 5 or 10 seconds, because if a search can take much
more then a minute a few more seconds doesn't matter...
johan
On Jan 29, 2008
do you have request that take more then 1 minute?
Wicket has to do that to make sure that you as a developer doesnt have to
think about multi threaded
programming and we as a framework also doesn't have to worry about 2 render
cycles at the same
time of the same page.
johan
On Jan 28, 2008
as for pulling, the page need to constantly refresh to check for new data and
i also need to manage order of the requests. shared resources sounds like
more close to how servlet would work. i am still new with wicket, is there
any example out there i can use as reference?
thanks for answering
btw, thank you for answer the question.
cemeterygate wrote:
that's nice to have but is there a way to work around this issue? Our
application for customer service and they perform a lot search on a huge
database, in some cases, customer service would like to start new search.
Since wicket
So I developed my first wicket application and I kept getting exception below
as soon as i point my application to production database.
Can someone tell me why wicket can't handle concurrent request?
to replicate this issue, i have a page with a form component and regular
submit button.
on the
that's nice to have but is there a way to work around this issue? Our
application for customer service and they perform a lot search on a huge
database, in some cases, customer service would like to start new search.
Since wicket is locked by page path, there is no way for CSR to start a new
sounds like wicket need Optimistic concurrency control =) i will try what you
guys suggested. I still feel weird, maybe i am thinking too much in servlet
world.
igor.vaynberg wrote:
cant we thread.interrupt() ? or will that actually kill the servlet
thread without restarting it? havent
yeah, if it takes a while the browser will timeout and you are screwed
anyways...
what do you mean they cant start a new search? you mean they no longer
for the results of the currently running search and just press the
search button again?
if they would open a new tab with the search page, and
maybe instead of waiting on the page to finish we should have an
option to kill it, rollback, and start again with the new request?
with the diskstore we have the old version serialized...
-igor
On Jan 28, 2008 2:51 PM, Johan Compagner [EMAIL PROTECTED] wrote:
shared resources are not synced
shared resources are not synced thats one way of going round it.
the other way is as igor describes. do the search in a seperate thread.
If it really takes that long then you do know that browsers also can just
time out after they don't get anything for a while?
If it really takes that long then
the pages are locked on the pagemap. so you cannot have two concurrent
requests from the same user to the same pagemap. this is so when you
are coding your pages you can use the much simpler single-threaded
model.
every have fields in your servlet implementation? those have to be
synchronized or
how do you kill a current request?
you can't shoot down the thread, and we dont have any control of what
somebody is doing..
Ofcourse when it comes back at an wicket entry point at some time at some
place we could check
for a specific boolean and just throw an exception... But that is pretty
error
interrupt() doesn't do much for a thread that isn't in wait/sleep or uses a
special nio interruptiblechannel
and most likely people have a try catch(Exception) around those and just go
on :)
johan
On Jan 29, 2008 12:26 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
cant we thread.interrupt() ? or
23 matches
Mail list logo
