Hi Peter,
the issue is in the difference between the HALTED and ZOMBIE states.
Session#close() sets the status to HALTED, and it will still be possible
to reopen it afterwards, e.g. to resume a long-running task. a ZOMBIE
session cannot be reopened and should just be stranded for GC.
I was not fully convinced of allowing a session to "commit suicide" with
a method where it sets itself to ZOMBIE. But anyway, that part of the
code has never been consolidated, it is still totally open to
refactoring. I haven't modified that policy ever since the code was
incubated in Apache.
Am I getting through to your question?
Best,
Alessandro
On 5/18/12 7:09 AM, Peter Ansell wrote:
I am browsing through the ontonet code trying to understand how it all
works and I found the following lines in
SessionManagerImpl.destroySession:
ses.close();
if (ses instanceof SessionImpl) ((SessionImpl) ses).state = State.ZOMBIE;
It seems a little strange that SessionImpl is treated differently here
to any other implementation of the Session interface. It is not clear
why the state would not be set properly in ses.close(), or rather why
it *couldn't* be set properly in ses.close for SessionImpl. If there
is a reason why it couldn't be set properly for SessionImpl then the
interface may need to change as other implementations could have the
same issue.
Is there an historical reason for this?
Cheers,
Peter
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
