[Design of JBossCache] - Re: Optimistic locking doesn't scale well with large 'flat'
by jason.greene@jboss.com
"bstansberry(a)jboss.com" wrote : "jason.greene(a)jboss.com" wrote :
| | I don't think there is a difference here. Pessimistic locking already allows phantoms by not forcing a write lock when nodes are added/remove.
|
By default, this is true, but there is a flag to acquire a write lock for node add/remove.
anonymous wrote :
|
| Yes, that's a good point. Since some people might want phantom prevention, and since optimistic locking has it now, we could make the lazy behavior optional, but default to true since isolation doesn't require it.
|
| anonymous wrote :
| | In the entity caching use case, the map is 100% sure to be read, so a lazy copy doesn't gain anything.
| | .
|
| To clarify, Does it ever call Node.getChildren() or Node.getChildrenNames? What I was meaning was that a direct node lookup (like "/a/b") can use the actual real node's child map, only a direct child map access by the application would require copying.
|
| -Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060072#4060072
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060072
16 years, 11 months
[Design of JBossCache] - Re: Optimistic locking doesn't scale well with large 'flat'
by bstansberry@jboss.com
"jason.greene(a)jboss.com" wrote : "manik.surtani(a)jboss.com" wrote : trying to get a child node will cache a null in the workspace if the child node doesn't exist - to maintain repeatable_read
| |
|
| Technically we don't have to do this, repeatable read allows phantoms, and they are still possible if the lazy loading occurs after a new child is created.
|
| anonymous wrote :
| | The drawback here is that it allows for s slight difference in semantics from pessimistic locking, due to the lazy locking (copying into workspace) of children .
| |
|
| I don't think there is a difference here. Pessimistic locking already allows phantoms by not forcing a write lock when nodes are added/remove.
By default, this is true, but there is a flag to acquire a write lock for node add/remove.
anonymous wrote : anonymous wrote :
| | Is this approach workable?
|
| Yes, another option is to just lazy copy the entire map the first time it is actually read.
|
In the entity caching use case, the map is 100% sure to be read, so a lazy copy doesn't gain anything.
In terms of entity caching, this should be workable since lockParentForChildInsertRemove=false for this use case.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060044#4060044
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060044
16 years, 11 months