SessionManagerImpl and State.ZOMBIE

[Peter Ansell <an...@gmail.com>]

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

Re: SessionManagerImpl and State.ZOMBIE

[Alessandro Adamou <ad...@cs.unibo.it>]

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