Re: Unable to release locks when using MultiECLockManager
Re: Unable to release locks when using MultiECLockManager
- Subject: Re: Unable to release locks when using MultiECLockManager
- From: Chuck Hill <email@hidden>
- Date: Wed, 30 Apr 2008 20:25:29 -0700
On Apr 30, 2008, at 4:24 PM, Owen McKerrow wrote:
Hi Again,
Please see below....
Owen McKerrow
WebMaster, emlab
Ph : +61 02 4221 5517
http://emlab.uow.edu.au
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - -
'The test of a first-rate intelligence is the ability to hold two
opposed ideas in the mind at the same time and still be able to
function.'
-F.Scott Fitzgerald,
On 30/04/2008, at 3:05 PM, Chuck Hill wrote:
On Apr 29, 2008, at 6:25 PM, Owen McKerrow wrote:
Hi Art,
Thats sounds like word for word the practices that we follow.
Although I did just double check the code to make sure and I found
a couple of places which had manual lock/unlock's in them which
should not have.
From Session.java
public void awake()
{
ecLockManager().lock();
super.awake();
.....
public void sleep()
{
// Need to check as this gets called after terminate() when
logging out
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
super.sleep();
}
I wrap anything other than super.... in try...catch(Throwable),
just in case.
Now this may be a basic Java question and I tried to ask it
yesterday, but probably in a very poor fashion.
When your dealing with overriding a method and the original method
does not throw an exception, but you do in your over-ride you
receive a compile error something like....
"terminate() in Session cannot override terminate() in Session;
overridden method does not throw java.lang.Exception"
Which means that any exceptions that are thrown you need to deal
with them at this methods level, correct ? Or is there a way to
throw them without this message appearing
In this particular case, I just logged the exception. IIRC, WO
swallows it anyway.
In general, I like Art's solution which ensures that super gets called
and does not require you to mess with exceptions:
public void awake() {
try {
ecLockManager().lock();
...
}
finally {
super.awake();
}
}
The pure WO way (and what Wonder also uses) is private API:
public void awake() {
try {
ecLockManager().lock();
...
}
catch (Throwable t) {
throw NSForwardException._runtimeExceptionForThrowable(t);
}
}
A non-specific WO way is described in http://www.javaspecialists.eu/archive/Issue033.html
Incidentally, that is a very good Java newsletter to subscribe to!
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden