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: Denis Stanton <email@hidden>
- Date: Fri, 21 Nov 2003 08:05:40 +1300
<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
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.
>> The subscription URLs would contain the
>> instance number <snip>
>>
> My solution to that was to catch these, strip off the instance number,
> and
> return a redirect. All with out creating a session. Direct actions
> can
> reference sessions and session data. That is why WO inserts the
> instance
> number when it generates a DA URL.
That's smarter than my fix.. After eliminating references to session I
took the low-tech approach and edited the URLs in iCal to remove the
instance number. I'm dealing with a small controlled user base here,
not public subscription.
> 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?
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.
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.
> 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 ? In the above
scenario would I have any locked editing contexts?
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?
> 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.
<message split because the list moderator is rejecting it for being
oversize. maybe I should take the hint and stop asking long questions>
_______________________________________________
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.