jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI vs Session.logout
Date Sun, 08 Oct 2006 18:42:44 GMT
Hi Angela,

thanks a lot for the good explanation about how you got where SPI is 
now. More inline...

Angela Schreiber schrieb:
>> I'm currently looking at SessionInfo (in the SPI API) and 
>> SessionImpl.logout() (in jcr2spi).
>>
>> It seems that the Session logout is handled entirely by the transient 
>> layer, and no SPI method is called to forward the information that the 
>> Session isn't used anymore. On the other hand, the SPI implementation 
>> may want to free resources related to the SessionInfo, right?
>>
>> Am I missing something, or is this an oversight?
> 
> you don't miss anything, nor is it an oversight.
> it's simply an open issue and there are many opinions, that
> don't fit together.
> 
> - initially the requirement was, that there is no (and never)
>   a 'session' hold on the server-side (server in the broader
>   sense). in this situation, both login and logout
>   didn't make any sense, since they insinuate, that there might
>   be some session hold below the SPI boundary.
>   this was the very initial state, where no 'login' was present.

Understood, and makes sense.

> - later on, some people claimed, that the 'SessionInfo' interface
>   is lost in the SPI and that it should be define, how the
>   SessionInfo is obtained.
>   in this situation, we added the 'login' method (which is probably
>   misnamed given the requirement). the current api reflects
>   this state.
> 
> - after that the login method has been a questioned in the first
>   jsr283 f2f and later on, since people thought, that 'login'
>   implies a stateful implementation.

Of course it begs the question where logout is :-)

> - and currently there a multiple requests for a 'logout' method,
>   in order to be able to keep some sort of Session identification
>   on the 'server'.
> 
> so... :)) since marcel and myself were busy with all kind of
> issues (mainly due to the id, that isn't an id any more),
> we didn't feel like fighting with opposed requirements
> and postponed the discussion (and a careful evaluation of all
> the pros and contras).

Some thoughts:

1) an SPI implementation of course will need to know on whose behalf 
requests are made; so at the very least some kind of user identification 
is needed. We currently have that in SessionInfo.

2) In many cases, an SPI implementation will also need to authenticate, 
thus it will need credentials. That's also in SessionInfo.

3) In some cases, an SPI implementation will have to keep it's own 
sessions open communicating to it's backend (JDBC connections, for 
instance). Of course an SPI implementation can control their lifetime 
(for instance, implementing a pool), but knowing when a session for a 
particular user isn't needed anymore would be very useful in any case.

So based on this I would recommend keeping SessionInfo, potentially 
rename "login" to something else ("obtain"?), and add a matching cleanup 
method ("close")...

Best regards, Julian








Mime
View raw message