[
https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479909#comment-13479909
]
Jukka Zitting commented on OAK-387:
-----------------------------------
There are two problems with leaving those resources in a "valid" state after
the session is gone:
* When the authenticated session is closed, the resources associated with it
must no longer have the associated access privileges. For example, a Root of an
admin session must no longer be allowed to commit() as an admin after the
session has been closed.
* There should be some way (other than relying on garbage collection) to
release large transient resources like uncommitted binaries or unmerged
branches when they are no longer needed. If the close() method on
ContentSession does not limit the lifecycle of associated Roots and Trees, then
those interfaces would need to also be Closeable.
bq. If we want to change this and make them "invalid" we'd need to track all
Root s spawned of from a content session and also "close" them once the content
session is closed.
A better approach would be to keep a reference to the ContentSession object in
the associated Root and Tree objects, and have them check the status of the
session whenever used for something that requires something covered by the
above two points.
> Clarify behavior/state of Root and Tree after calling ContentSession#close()
> ----------------------------------------------------------------------------
>
> Key: OAK-387
> URL: https://issues.apache.org/jira/browse/OAK-387
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: angela
>
> quickly discussed this topic with jukka today in the office.
> as far as i know the API contract does currently not specify what happens
> to (the state of) a Root or Tree once the ContentSession has been closed.
> if i am not mistaken, the current implementation would just loose
> the permissions that were granted to the original subject... but that's
> rather a coincidence (and i didn't test it to verify that's really the case)
> possible solutions could be:
> - upon session closure the root/tree becomes invalid (invalidstate) and throws
> - the root/tree are still valid but doesn't have the original permissions
> any more -> default permissions for empty-subject would apply
> - ...
> whatever solution we may prefer in the end, i think that API contract should
> state the expected behavior (even if it was "undefined") and we should have
> tests verifying the current implementation does what we think it should do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
