Am 06.09.2007 um 00:39 schrieb Mike Schrag:
If you see problems in the stacktrace, when the session gets
checked out from the session store, make sure you NEVER EVER touch
something from the session's default editing context inside your
"performAction" method on a long response page. This
"If virtue
can't be mine alone
at least my faults
can be my own."
- Piet Hein
Deadlocks in WebObjects have always been my own fault. I'm thankful to
Andrew Lindesay's HOWTO. It's a super easy process -- and saves my bacon
from my own carelessness.
> From: Steven Mark McCraw <[EMAIL PROTECT
Is it easy? Or is that just the nature of the concurrency beast?
I consider it easy because I've had to deal with it so many times. I
think WebObjects seems worse than a normal multithreaded app because
things you do that are totally unrelated to concurrency from the
programmer's point o
On Sep 5, 2007, at 4:12 PM, Steven Mark McCraw wrote:
You are probably safe for general EC usage there, but you can
still do other bad things and end up deadlocked.
There are many great things in the "win" column for WebObjects, but
I believe one of the definite negatives of the technology
You are probably safe for general EC usage there, but you can still
do other bad things and end up deadlocked.
There are many great things in the "win" column for WebObjects, but I
believe one of the definite negatives of the technology is how
ridiculously easy it is to deadlock a webobject
On Sep 5, 2007, at 3:01 PM, Simon McLean wrote:
Hi -
We're experiencing some pretty bad deadlock issues at the moment
and I'm pretty convinced it's down to EC lock abuse.
What makes you think that? As Guido indicated, if you don't have
stack traces you are just guessing. Guessing is no
If you see problems in the stacktrace, when the session gets
checked out from the session store, make sure you NEVER EVER touch
something from the session's default editing context inside your
"performAction" method on a long response page. This will autolock
your session's default editing
On 05.09.2007, at 16:01, Simon McLean wrote:
We're experiencing some pretty bad deadlock issues at the moment
and I'm pretty convinced it's down to EC lock abuse.
Get a stacktrace of your running application to verify that:
http://tinyurl.com/3bpkkv
... we should never have to manually loc
Hi -
We're experiencing some pretty bad deadlock issues at the moment and
I'm pretty convinced it's down to EC lock abuse.
Can anyone confirm that if we follow these rules:
** If you do want all that Wonder magic and love:
1) extend ERXApplication
2) extend ERXSession
3) use ERXEC.newEditing
On Sep 5, 2007, at 1:10 AM, Daniele Corti wrote:
Hi all,
I've a problem with my last app:
We use our app as a WebService that provide license for our
products and donwload upgrades, and a Web Site for Support.
It has happen (today) that we make some changes, so shutdown the
app, wh
On 05.09.2007, at 07:05, Daniele Corti wrote:
I don't think I will need a too accurated value, I only need to
know if a variable in the Session is setted: I mean, I use an
Enterprise Object GWSUser to memorize witch user is logged in in
each session, so I only need to know if it there are u
2007/9/5, Mike Schrag <[EMAIL PROTECTED]>:
>
> Be very careful accessing values of a session ... Make sure you lock
> properly.
>
Well, I'm only reading them, not writing
On Sep 5, 2007, at 9:05 AM, Daniele Corti wrote:
>
>
>
> 2007/9/5, Mike Schrag <[EMAIL PROTECTED]>:
> >
> > Assuming you're no
Be very careful accessing values of a session ... Make sure you lock
properly.
On Sep 5, 2007, at 9:05 AM, Daniele Corti wrote:
2007/9/5, Mike Schrag <[EMAIL PROTECTED]>:
Assuming you're not using a servlet deployment:
WOServerSessionStore sessionStore = (WOServerSessionStore)
WOAp
2007/9/5, Mike Schrag <[EMAIL PROTECTED]>:
>
> Assuming you're not using a servlet deployment:
>
> WOServerSessionStore sessionStore = (WOServerSessionStore)
> WOApplication.application().sessionStore();
> NSArray sessions = sessionStore._sessions().allValues();
>
Thanks that's what I
Assuming you're not using a servlet deployment:
WOServerSessionStore sessionStore = (WOServerSessionStore)
WOApplication.application().sessionStore();
NSArray sessions = sessionStore._sessions().allValues();
Note that this will only return the sessions that exist within a
single
Hi!
The constructor is an odd place for this.
The constructor is called from pageWithName(). That is in the request-
response loop preceding the one that would actually use the component.
If you already know at that point in time where you want to go and
where not, you should modify the cal
Hi all,
I've a problem with my last app:
We use our app as a WebService that provide license for our products and
donwload upgrades, and a Web Site for Support.
It has happen (today) that we make some changes, so shutdown the app,
while someone was downloading an update.
You can easly
17 matches
Mail list logo
