Re: WO instance locks up and won't die - part 1
Re: WO instance locks up and won't die - part 1
- Subject: Re: WO instance locks up and won't die - part 1
- From: Chuck Hill <email@hidden>
- Date: Thu, 20 Nov 2003 20:24:49 -0800
Hi Denis,
At 08:05 AM 21/11/2003 +1300, Denis Stanton wrote:
>>>>
<message re-edited because the list rejected it as oversize)
Hi Chuck
I'm getting a bit lost here. I'll try and answer the questions you've put
back to me.
On Thursday, November 20, 2003, at 06:31 PM, Chuck Hill wrote:
At 01:29 PM 20/11/2003 +1300, Denis Stanton wrote:
I'm only using the defaultEditingContext in my components (excluding
direct actions). I don't lock or unlock any ECs.<snip>
A null pointer exception shoulnd't cause a session to become immortal, but
it has in past versions. <snip> Do you do anything in Session.terminate or
session.finalize?
I don't think I put my description of the use of ECs in my app very clearly.
I have twenty of so components manipilating 42 entities. They all use
session().defaultEditingContext when fetching. I'm sure someone wrote that
as long as I was only using defaultEditingContext I didn't have to
lock/unlock the EC
Correct.
I also have a small group of direct actions. They select some rows from a
table (sorry, an entity) and return them in iCal format. These were
originally calling session().defaultEditingContext too, but that meant that
if 4 iCal subscriptions refreshed every 15 minutes I was getting 4 x 4
sessions generated per hour, which were then hanging around for an hour
each, event though they had served their purpose in a few seconds. I
switched them to make their own ECs so that session() didn't come into it.
Sounds like a reasonable solution.
There is no timeout so it pretty much lives up to it name. The only two
solutions are to prevent deadlock and to detect it and terminate the app
abuptly.
OK, so a deadlock is a deadlock. The trouble is I don't know where the
deadlock is, if it exists. I have a bunch of tables all linked to each
other in EOF. The application is a rental vehicle booking system. The
users look at things, change things, save changes. Relationships between
customers and products and price lists and dates are added and deleted, all
normal stuff. I'm saying I have a deadlock because sometimes an instance
seems to become stuck, but really I don't know if it's a deadlock or how to
avoid it. I remember worrying about deadlocks when I was a Cobol
programmer a long time ago, but I don't know how you get a deadlock when
all WO/EO is doing is sending a bunch of SQL selects and updates to a
database (to over simplify hugely)
Surely an SQL select will always work if you name the attributes correctly,
and the worst an SQL update can do is "update no rows" because optimistic
locking was overly optimistic. So where does the deadlock occur?
Judging from your recent posting it looks as if deadlock is not your
problem. The dead I am referring to is as the level of a WOSession or
EOEditingContext level, not at the database, and is the result of an error
in Java not SQL. It does not sound like what you are doing could produce
an ec deadlock.
Sometimes I get a null pointer exception. This can usually be traced to my
code. This morning we had one when my user decide to erase a value in a
textfield bound to an Integer instead of replacing it with zero as I had
done in testing. I had left the default Allow Null set in EOM. This
allowed the component to save null to an integer attribute, but then it
tried to use it for something and I got Null Pointer. Programmer error,
easily fixed by being more careful. But could this cause the session to
become stuck, but which I mean it remains in RAM and in the count of
sessions for that instance, but no longer responds? I don't think so,
because if the user presses the browser's back button (though they
generally shouldn't) and goes somewhere else the session is still usable.
Most of the time.
Depending on where and when it happened and which version of WO, yes that
could cause a session to get stuck and never terminate.
About once each day I see the number of sessions rise to more than the
number of client computers. (we're talking single figures here - or at
least it should be). If I see 20 session for 5 users I don't think it
implies subtle use of tabbed browsers. Rather it means that a user finds
that their session is not responding and "logs in again". I have tried to
identify the action that causes the problem without success. JavaMonitor
doesn't tell me which sessions are not responding. The only way I know I
have a bad one is to set refuse new sessions, start a replacment instance
and wait. If the transaction count does not increase then the instance is
not in use and you would expect all sessions for the instance to time out
inside an hour. If both transaction and active session counts remain fixed
for more than an hour I know I have a problem and the instance cannot be
stopped.
That definately sounds like a problem with sessions getting checked out and
not checked back in. The next request for that session blocks waiting for
the first thread to check it back in. That never happens and you have,
well, deadlock. If you are not dispatching requests concurrently the whole
app should just lock up with noone able to do anything. You are
dispatching concurrently so just that one session locks up.
The problem is bugs in the WO code that do not appropriate catch and handle
exceptions. These can result in a session not getting checked back in and
/ or an editing context not getting unlocked.
You lost me. What is session check out / check in ?
See WOSessionStore.
In the above scenario would I have any locked editing contexts?
Not directly.
Does session check out just mean that a response is given an identifying
number so that the next request from the same browser can be recognized and
applied to the correct session?
No. Access to session is serialized, only one thread is granted access at
a time. Check out and check in is how this is regulated.
On the next reference to the
locked session or EC your app just stops unless it processes requests
concurrently. In the latter case it keeps going on. For a while...
Concurrent dispatch is a crutch not a solution for this problem.
I have:
public Application() {
super();
System.out.println("Welcome to " + this.name() + "!");
System.out.println(" SMTPHost = " + this.SMTPHost());
/* ** Put your application initialization code here ** */
setAllowsConcurrentRequestHandling(true);
}
I don't remember adding the setAllowsConcurrentRequestHandling(true). I
went to put it in following an earlier discussion and it was there already.
Now I'm wondering if I should try setting it false.
If you do your app will lock up when the first session does. At least then
you will know right away but your users might not be so happy.
<message split because the list moderator is rejecting it for being
oversize. maybe I should take the hint and stop asking long questions>
Maybe they should take the hint and increase the limit! :-)
<<<<
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.