Sunday, October 21, 2007
Hibernate
According to Hibernate Sessions and transactions, implementing unit of works using Session-per-conversation is preferred over session-per-request-with-detached-objects. In Chapter 11 of hibernate manual, it's stated that CurrentSessionContext should be implemented but I haven't found the example on the wiki. Help?
Grid computing / distributed computing frameworks
- Globus Toolkit:
- Terracota: Transparent Clustered JVM
- GigaSpaces
- Coherence
Terracota
http://www.terracotta.org/
Doubts:
Doubts:
- Question: What if you don't want to replicate state through all nodes in the grid? HTTP Session replication can be VERY expensive.
Answer: http://www.terracotta.org/confluence/display/orgsite/HTTP+Session+Clustering - Question: How about resources such as JDBC connections? Will each node be able to establish their own connections? Furthermore, can they have their own configurations?
Answer: http://www.terracotta.org/confluence/display/orgsite/Hibernate
Monday, September 17, 2007
Hibernate Shards
From: http://www.hibernate.org/hib_docs/shards/reference/en/html/shards-shardstrategy.html
"It's important to note that if a multi-level object graph is being saved via Hibernate's cascading functionality, the ShardSelectionStrategy will only be consulted when saving the top-level object. All child objects will automatically be saved to the same shard as the parent. You may find your ShardSelectionStrategy easier to implement if you prevent developers from creating new objects at more than one level in your object hierarchy. You can accomplish this by making your ShardSelectionStrategy implementation aware of the top-level objects in your model and having it throw an exception if it encounters an object that is not in this set. If you do not wish to impose this restriction that's fine, just remember that if you're doing attribute-based shard selection, the attributes you use to make your decision need to be available on every object that gets passed to session.save()."
If you were to save child objects in a different shard, will you be able to enforce foreign key constraint? More generally, is it possible to enforce cross-shard integrity reference? Answer below (http://www.hibernate.org/hib_docs/shards/reference/en/html/shards-resharding.html):
"Unfortunately, the problem of changing object-shard mappings becomes even worse once we consider the fact that Hibernate Shards does not support cross-shard relationships (meaning FKs). This limitation prevents us from moving a subset of an object graph from one shard to another."
"It's important to note that if a multi-level object graph is being saved via Hibernate's cascading functionality, the ShardSelectionStrategy will only be consulted when saving the top-level object. All child objects will automatically be saved to the same shard as the parent. You may find your ShardSelectionStrategy easier to implement if you prevent developers from creating new objects at more than one level in your object hierarchy. You can accomplish this by making your ShardSelectionStrategy implementation aware of the top-level objects in your model and having it throw an exception if it encounters an object that is not in this set. If you do not wish to impose this restriction that's fine, just remember that if you're doing attribute-based shard selection, the attributes you use to make your decision need to be available on every object that gets passed to session.save()."
If you were to save child objects in a different shard, will you be able to enforce foreign key constraint? More generally, is it possible to enforce cross-shard integrity reference? Answer below (http://www.hibernate.org/hib_docs/shards/reference/en/html/shards-resharding.html):
"Unfortunately, the problem of changing object-shard mappings becomes even worse once we consider the fact that Hibernate Shards does not support cross-shard relationships (meaning FKs). This limitation prevents us from moving a subset of an object graph from one shard to another."
Subscribe to:
Posts (Atom)
