[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1250) Add a Node.clearChildren() functionality

Tue Aug 5 10:45:58 EDT 2008

    [ https://jira.jboss.org/jira/browse/JBCACHE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12423648#action_12423648 ] 

Brian Stansberry commented on JBCACHE-1250:
-------------------------------------------

No, my post was focused on priorities; i.e. how necessary this functionality really is for my use case.

Re: cost, if the functionality is absolutely required in order to have correctness, then I think the cost is OK. But per the forum thread it seems it's not absolutely required for my use case.

Re; lockParent, I agree with what you're saying. Using Hibernate 2LC as a concrete example, someone could execute a bulk SQL operation, which is what triggers Hibernate to flush the cache by removing the root node for the entity type. If the DB is READ_COMMITTED, simultaneously a DB read/cache PFER operation could be going on that caches a now invalid entity. Wrong. And for the Hibernate case, having lockParent=true is absolutely not an option. So, again, for the Hibernate 2LC case, adding this API method doesn't guarantee correctness.

> Add a Node.clearChildren() functionality
> ----------------------------------------
>
>                 Key: JBCACHE-1250
>                 URL: https://jira.jboss.org/jira/browse/JBCACHE-1250
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Manik Surtani
>             Fix For: 3.0.0.GA
>
>
> For next major API change.
> Equivalent to Node.clearData(), but removes the children.
> Use case is trying to atomically remove everything under some structural node, while leaving the structural node in place. The best that can be done now is either:
> 1) Remove the node and re-add it, but this doesn't work for remote caches with INVALIDATION, since both the removal and the addition propagate as invalidation messages. Remote caches are left w/o the structural node. Plus it's not atomic.
> 2) Query for the children and remove them one by one.  Also not atomic, plus if lockParentForChildInsertRemove is false you have to deal with other threads possibly adding new children while you are removing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira