"adrian(a)jboss.org" wrote : "b_georges" wrote :
| | Unassigned
| |
| | 37) http://jira.jboss.com/jira/browse/JBMICROCONT-179: VFS caches old jar files - Unassigned
| |
|
| This is likely to disappear when we move to the VFS classloader.
| So it will a non-issue?
| Needs doing for 2.0.0
|
I believe so, and as I said it has not been reproducible when I included the url handler code source in the bootstrap classpath. We do need to make sure there are tests for updating jar files and seeing that the updated contents have changed. There is at least one test for this, but it should be expanded to include all crud scenarios.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060036#4060036
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060036
"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.
anonymous wrote :
| Is this approach workable?
Yes, another option is to just lazy copy the entire map the first time it is actually read.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060017#4060017
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060017