i agree with johan,the web is based around processing a lot of short lived requests. if you have something that takes a long time do it in a separate thread with some kind of notification. now what we may need is support for long-running tasks that makes implementing them and their notifications tr
pdf generation and that kind of stuff should be done in a seperate thread.Else you could have browser just time out your request. And with an ajax call/progress bar it is also much nicer.FileUpload would be a thing that we can optimze (if that is not already the case or something like that) that th
the thing is that an application in the 90% group may evolve into the 10%
group. it may be a simple thing such as a new report, pdf generation, file
upload or anything else. it seems easy to add to your application, but then you
discover that it influences all of it. and, there's no way out.
e
Especially if you have a user object retrieved from the database using
Hibernate in your sessoin, that will not work when handling multpile
requests.
A hibernate object can only be attached to one hibernate session at a
time. It is a very convenient and useful programming paradigm to put
such obje
As Matej already said that will be to difficutl internally in wicket (for example the rendering of a page and another thread setting stuff like new components)And for the developer code itself. Threading is one of the most difficult things there is in programming, there are so many loopholes.
So we
I can say that current synchronization policy of wicket seems to me too
coarse grained.
But having no synchronization at it would be very easy to achieve
inconsistent internal state. There's no easy way around this right now.
There was a thread about this lately, maybe you'll find something the
anyone care to comment?
just to reiterate the problem: if i work with two windows/tabs, pointing to the
same wicket app, and in one i do some lengthy operation, then in the other i
cannot work. i'm not sure if this is the case, but if i want to build a flicker
like site, then i can't browse the
Johan Compagner wrote:
> if you don't lock then pages and sessions must take care of that they
> are not thread safe
> currently wicket is for the most part (99%) thread safe.
>
> Maybe we could loose it a bit and say we only sync around the active page.
> But then if you hold a page in another
if you don't lock then pages and sessions must take care of that they are not thread safecurrently wicket is for the most part (99%) thread safe.Maybe we could loose it a bit and say we only sync around the active page.
But then if you hold a page in another page. And set that as a respond then we
thanks for the quick response.
is there any way around it? what happens if i don't lock?
Matej Knopp wrote:
> Ittay Dror wrote:
>> this is from RequestCycle:
>> private final void processEventsAndRespond()
>> {
>> // Use any synchronization lock provided by the target
>>
Ittay Dror wrote:
> this is from RequestCycle:
> private final void processEventsAndRespond()
> {
> // Use any synchronization lock provided by the target
> Object lock = getRequestTarget().getLock(this);
> if (lock != null)
>
this is from RequestCycle:
private final void processEventsAndRespond()
{
// Use any synchronization lock provided by the target
Object lock = getRequestTarget().getLock(this);
if (lock != null)
{
sync
12 matches
Mail list logo
