Menu
▾
▴
jboss-dev-forums
|
From: <bst...@jb...> - 2006-06-22 23:47:06
|
I mentioned before that I found another problem that seems to call for the use of a flat heap.
See unit test o.j.c.buddyreplication.aop.BuddyReplicationFailoverTest. This test currently fails due to JBCACHE-669, but even if 669 were resolved the test would still fail due to the following problem:
2 Person objects, with a shared reference to an Address. Using buddy replication.
1 Person is placed in Cache 1 under "/husband" then the other is placed in Cache 1 under "/wife". The address is stored in "/husband/address" -- "/wife/address" just has an indirect pointer to "/husband/address".
Cache 1 dies. User fails over to Cache 2.
1) User calls getObject("/wife").
2) This causes node's "/wife" and "/wife/address" to gravitate.
3) User call wife.getAddress().
4) JBCACHE-669 is fixed, so this causes "/_JBossInternal_/_RefMap_/husband_address" to gravitate.
5) PojoCache deferences and follows the RefMap entry to "/husband/address", so node "/husband/address" is gravitated.
6) Gravitating "/husband/address" *does not cause the data map of "/husband" to gravitate*!!! Rather, Cache 2 just creates an empty node at "/husband" to maintain the tree structure.
7) User calls getObject("/husband"). This returns null, because node "/husband" does not have any data. No data gravitation is performed, because the "/husband" node *exists* in Cache 2.
The fundamental problem here is the intermingling of the TreeCache structure with the storage of data. You can't access the Address object without involving the concept of "husband", which leads to all sorts of problems.
BTW, I don't think this particular issue has to be fixed for 1.4.0 -- we could just say BR is for plain cache operations. However, JBCACHE-669 does need to be fixed, as FIELD replication does not work correctly without it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952840#3952840
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952840
|
|
From: <ben...@jb...> - 2006-06-23 06:24:47
|
Yes, this is something that I plan to do. Not necessary to store all the internal node under the same _HEAP_ space since issues such as locking needs to be taken into account. Secondly to address your second post, a better solution like I mentioned in my previous reply to your forum post, is to have _JBOSS_INTERNAL_ to reside into an individual region. This way, again, we assume the object relationship only has the scope within that region. But this should be a perfect assumption. For example, within a webapp, we don't expect the relationship to persist across the different webapps, right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952884#3952884 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952884 |
|
From: <bst...@jb...> - 2006-06-23 18:53:55
|
IMHO, a flat heap *improves* locking semantics by making them more like standard java locking. E.g. in standard Java if you have a Person with a sub-object Address. One thread has a ref to the Address; another thread has a ref to the Person. If the 2nd thread synchronizes on the Person, that doesn't prevent the 1st thread updating the Address. PojoCache would prevent an update to the Address if the Person has been updated. But, AFAICT, only sometimes! If Address is stored in /husband/address, an update to /husband locks address. But an update to /wife with an indirect ref to /husband/address doesn't lock the Address. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953107#3953107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953107 |
|
From: <be...@jb...> - 2006-06-26 07:08:24
|
Ben, do we have a JIRA issue regarding this ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953345#3953345 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953345 |
|
From: <be...@jb...> - 2006-06-26 07:09:41
|
+1 on this. Allocating a child node for a complex field (e.g. address) creates an unwanted dependency between parent-child which doesn't exist in real life, as an address can exist independently of a person View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953346#3953346 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953346 |
|
From: <ben...@jb...> - 2006-06-26 10:51:49
|
Yeah, http://jira.jboss.com/jira/browse/JBCACHE-589 Per our discussion in Vegas, this is the direction that I am going as well. I have been trying to walk through couple of use cases to see if there is any hole to it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953397#3953397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953397 |
|
From: <be...@jb...> - 2006-06-26 11:04:23
|
The 589 doesn't look like the flat heap task, that one is about pojo level locking. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953401#3953401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953401 |
|
From: <ben...@jb...> - 2006-06-26 11:38:04
|
Oops! Sorry. :-) I mean this that I have created a while ago: http://jira.jboss.com/jira/browse/JBCACHE-173 I have added the link to this post and will update it further later. I am planning to implement the flat space approach in 2.0 (or 2.1) depending on the release schedule, I think. On the locking semantics to match the Java one, one thing that I have mentioned previously in the Jira is that if I have an example like the following: | Person p1 = new Person(); | Address addr = new Address(); | | cache.attach(p1); | cache.attach(addr); | | p1.setAddress(addr); | Then if thread 1 is doing: | tx.begin(); | p1.setBlah(); | ... | thread 2 will be blocked in this operation as well: | p1.getAddress().setZip(95123); | Same thing that if thread 2 goes first, then thread1 is blocked as well. In Java, the behavior really depends on whether syncrhonized(this) is used for all of the methods or not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953407#3953407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953407 |
|
From: <ben...@jb...> - 2006-06-28 13:16:47
|
"bst...@jb..." wrote :
| 2 Person objects, with a shared reference to an Address. Using buddy replication.
|
| 1 Person is placed in Cache 1 under "/husband" then the other is placed in Cache 1 under "/wife". The address is stored in "/husband/address" -- "/wife/address" just has an indirect pointer to "/husband/address".
|
| Cache 1 dies. User fails over to Cache 2.
|
| 1) User calls getObject("/wife").
| 2) This causes node's "/wife" and "/wife/address" to gravitate.
| 3) User call wife.getAddress().
| 4) JBCACHE-669 is fixed, so this causes "/_JBossInternal_/_RefMap_/husband_address" to gravitate.
| 5) PojoCache deferences and follows the RefMap entry to "/husband/address", so node "/husband/address" is gravitated.
| 6) Gravitating "/husband/address" *does not cause the data map of "/husband" to gravitate*!!! Rather, Cache 2 just creates an empty node at "/husband" to maintain the tree structure.
| 7) User calls getObject("/husband"). This returns null, because node "/husband" does not have any data. No data gravitation is performed, because the "/husband" node *exists* in Cache 2.
|
| The fundamental problem here is the intermingling of the TreeCache structure with the storage of data. You can't access the Address object without involving the concept of "husband", which leads to all sorts of problems.
|
| BTW, I don't think this particular issue has to be fixed for 1.4.0 -- we could just say BR is for plain cache operations. However, JBCACHE-669 does need to be fixed, as FIELD replication does not work correctly without it.
Brian, I have thought about this issue while designing the new mapping scheme. While the scenario that you mentioned can happen, I think it is more unlikely. The reason being that buddy replication requires "sticky session" to operate in cases like http session repl.
If it is http session repl, then every data structure will be stored under a sessionID. In this case, my undertanding is we will gravitate everything under sessionID in one shot during failover, am I correct. Therefore, shared reference between "joe" and "mary" will still work, for example.
Using a flat mapping on the other hand, will require, during gravitation, the special need to gravitate the corresponding _JBoss_Internal_ area (since everything is stored in the internal flat heap now). In essence, we will need to walk the object graph.
For example, I am thinking what will be the best behavior for data gravitation, if after failover I do a:
| joe = getAttribute("joe", joe);
| joe.getName();
|
should we also gravitate the corresponding address field as well. Or just lazily gravitate it when needed? E.g., when
| joe.getAddress().setCity("Taipei");
|
is called?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954000#3954000
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954000
|
|
From: <bst...@jb...> - 2006-06-28 22:12:26
|
"ben...@jb..." wrote : | Brian, I have thought about this issue while designing the new mapping scheme. While the scenario that you mentioned can happen, I think it is more unlikely. The reason being that buddy replication requires "sticky session" to operate in cases like http session repl. | | If it is http session repl, then every data structure will be stored under a sessionID. In this case, my undertanding is we will gravitate everything under sessionID in one shot during failover, am I correct. Therefore, shared reference between "joe" and "mary" will still work, for example. Yes, definitely. That's why this issue was not a big priority for me for 1.4.0 -- the session replication use case works even if this issue isn't resolved. Re: walking the object graph and gravitating aggressively vs. lazy gravitation, my instinct is that walking the object graph and gravitating aggressively would be more performant. Otherwise you end up doing a bunch of single node gravitations at random points. I could be wrong though. For example, gravitation now is a 2 step process: 1) Please give me everything under Fqn x -- return is a list of NodeData objects. 2) Please remove everything you had under Fqn x, as I now own it. This is a simple call, I just pass "x". Doing it in 2 steps is important as you avoid removing the data from the old backup node until the new owner acknowledges he's received it. With a flat heap it becomed more complex: 1) Please walk an object graph starting at x and give me all nodes. 2) Please rewalk that object graph, but now delete all nodes you have. I guess that's not that different, but it is different. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954200#3954200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954200 |
|
From: <ben...@jb...> - 2006-06-30 01:33:01
|
Yeah, active loading is what I have in mind. As a matter of fact, if we can safely assume that all BR will a corresponding session ID fqn associated with it, then all we need is graviate it twice: one on the regular /JSESSION/sessionId and one on _JBOSS_INTERNAL/sessionId. All the object graphs should be contained within. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954553#3954553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954553 |
Thanks for helping keep SourceForge clean.
X