[hibernate-issues] [Hibernate-JIRA] Commented: (OGM-79) Abstract GridDialect from Infinispan's Cache API
Emmanuel Bernard (JIRA)
noreply at atlassian.com
Fri Oct 28 11:53:23 EDT 2011
[ http://opensource.atlassian.com/projects/hibernate/browse/OGM-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44195#comment-44195 ]
Emmanuel Bernard commented on OGM-79:
-------------------------------------
Here is a discussion between Emmanuel and Sanne on the role of a DatastoreManager and the GridDialect
{quote}
sannegrinovero hi emmanuel 17:12
sannegrinovero still here 17:12
emmanuel sannegrinovero: yep 17:12
emmanuel So in OGM 17:12
emmanuel if you look at GridDialect 17:12
emmanuel we do pass infinispan's Cache methoid 17:12
emmanuel That's obviously not very portable 17:13
emmanuel I have been thinking about ways to solve the problem 17:13
emmanuel I se 17:13
emmanuel I initially thought about creating an abstraction for Cache and replace the API verbatim 17:13
sannegrinovero I was going to talk you about the same thing 17:14
emmanuel But I now think that we probably should internalize Cache lookup into a NoSQL provider specific abstraction 17:14
emmanuel Technically form the key the provider is able to lookup the right cache 17:14
emmanuel I've looked at the code and we do cache lookup right before calling the dialect anyways 17:15
sannegrinovero even more than that, you might want to extract the specific operations and define them on the dialect instead of returning the Cache 17:15
emmanuel Not following you 17:15
sannegrinovero because some "dialects" might need some specific tricks to do some stuff better 17:15
sannegrinovero well right now you expose the Map API to the OGM engine 17:15
emmanuel the dialect already does define generic operations 17:16
emmanuel no 17:16
emmanuel I expose the Tuple API 17:16
sannegrinovero but Infinispan works better if you enable the specific Flag (s) to tune each specific need 17:16
sannegrinovero ah right, was confused 17:16
emmanuel So that's my current thinking 17:17
emmanuel We have two approaches I guess 17:17
emmanuel Have the notion of DatastoreManager that is passed to the dialect 17:17
emmanuel or leave the dialect do all the work 17:17
emmanuel I'm not sure what's best yet 17:18
emmanuel For sure, the engine will only interact with the dialect 17:18
emmanuel (except for initialization) 17:18
emmanuel Any thoughrs? 17:19
sannegrinovero is abstractin Cache the only reason, or are there more ? 17:19
sannegrinovero just to figure out which problems need to be solved 17:19
sannegrinovero My idea is that at some point we will need two levels of asbtraction, an intermediate layer to talk to all key/value stores, and a higher layer which doesn't care of it's key/value or what, and the lowest coupled to Infinispan 17:20
sannegrinovero also, for the specific k/v stores we could use the JSR-347 API 17:22
emmanuel sannegrinovero: I don't know but I hope th tuple API is generic enough for all noSQL solutions 17:22
emmanuel Loader and Persisters might be specific though 17:22
sannegrinovero right 17:23
emmanuel My concern with delegating cache lookups to extension points is the following 17:23
emmanuel putting all entities in a single cache or splitting one entity type per cache becomes a dialect implementation detail 17:23
emmanuel which I am not found of 17:23
sannegrinovero right, in fact some users might even prefer to use OGM with a single cache for all. 17:24
sannegrinovero don't know if you noticed it too, but the ServiceRegistry thing in Hibernate Core 4 is slowing down things, not much but it does. 17:24
sannegrinovero it might be a great pattern to enable the flexibility needed for H4, but if we can design it in such a way to avoid lookups per operation that would definitely be better 17:25
emmanuel sannegrinovero: that's ok we can cache services registry lookups down the road 17:26
emmanuel eg in the persister and the loaders 17:27
sannegrinovero so in practice the question is if we want the InfinispanDialect to keep references to the CacheManager ? 17:28
sannegrinovero that would be the approach of "leaving all the work to the Dialect" right? 17:28
emmanuel If I try and summarize what is specific to a NoSQL provider and thus abstracted is:
- how to create, update, delete entities (fundamental op)
- how to create, update, delete collections (fundamental op)
- how to boot the DatastoreManager (ie how to connect to the datastore engine)
- how to access a given datastore (or cache in ispn's cache)
- possibly later which persister / loader family to use 17:29
sannegrinovero and queries. Some engines do have queries. 17:30
emmanuel sannegrinovero: right about queries amd ref to the cache manager 17:31
emmanuel s/amd/and the/ 17:31
sannegrinovero what about transactions, is it possible some might have a transactions "surrogate" which needs to be accessed in different way? 17:32
emmanuel I guess 17:32
emmanuel we will see 17:32
sannegrinovero yes I'm guessing too, but don't know if any have such a thing. 17:32
sannegrinovero but you could consider that another point for your list of stuff which needs possibly to be delegated to the dialect 17:33
emmanuel I guess we do need a DatastoreManager API that will be responsible for answering all these questions 17:33
emmanuel the question remaining is do we keep a notion of dialect 17:33
emmanuel something tells me yes 17:33
emmanuel for example in ISPN, one can thing of different storage strategies 17:33
emmanuel implemented by dialects 17:33
sannegrinovero I'm also thinking so, but maybe we should constrain it's meaning to some operations, it will not be fit for all things. 17:34
emmanuel whereas the rest of the Datastore bootstrap does not changes 17:34
sannegrinovero so the dialect could be the thing which abstracts CRUD for entities and relations 17:34
sannegrinovero but nothing else 17:34
emmanuel like it is today yes 17:34
emmanuel though it does use NoSQL native APIs 17:34
sannegrinovero a bit tricky the relations part, as it might benefit from queries instead of FG Maps 17:35
sannegrinovero so it would depend on the query engine 17:35
emmanuel that's unlike the Hibernate Core dialects that is more a question / answer API used by the engine 17:35
emmanuel It looks like GridDialects will need access to the DatastoreManager anyways 17:36
sannegrinovero right, that's my thought as well 17:36
sannegrinovero but are you going to pass it on a per-invocation, or at initialization? it looks like to me a good candidate for a final 17:38
emmanuel One thing I woner about is whether or not the user should be involved in these choices / decisions 17:38
emmanuel ie can a user plug a diff query engine (assuming we have several ) 17:39
sannegrinovero mm... like sharding ideas, on multiple instances of a nosql, or possibly on different kinds ? 17:39
sannegrinovero yes I would make that possible, but is of course not a priority 17:39
emmanuel if the user is involved, then the DatastoreManager can provide "default anwers for the dialect, query engine etc 17:39
emmanuel but nto the final one 17:39
emmanuel re final. yes that will be passed at initialization but… interfaces, initialization and final values don't play well together as you know 17:40
emmanuel so should a dialect have a initialize(Something) method 17:40
emmanuel or should we enforce a Constructor(Something) 17:41
emmanuel (not type safe 17:41
emmanuel ) 17:41
sannegrinovero why not typesafe? 17:41
sannegrinovero you know I like constructors 17:41
emmanuel If I forgot the Constructor in the dialect, I'll get a runtime exception 17:41
emmanuel not a compile time exception 17:42
sannegrinovero right but you'll get it immediately at boot time, not "after a while in production.." 17:42
emmanuel correct 17:42
sannegrinovero well I'm fine for initialization methods too, it's just more tricky to get it right when the service is accessed concurently 17:43
sannegrinovero but it's doable 17:43
sannegrinovero and that implementation detail won't be checked at compile time either 17:43
emmanuel Multi cores are a thing of the past anyways 17:44
emmanuel don't bother with synchronization 17:44
sannegrinovero right now it's the eras of persistence framework which support SERIALIZABLE only 17:44
emmanuel and transactional datagrids that use hypra optimistic tx strategies aka some commits win 17:45
sannegrinovero 17:45
sannegrinovero I'll have to go in a couple of minutes, or gf kills me 17:46
sannegrinovero in an unrelated parenthesis, I found this proposal from Stark very interesting, if you have time to ponder about the possibilities: community.jboss.org/thread/174167 17:46
emmanuel np 17:47
sannegrinovero I think we concluded the dialect will need the instance right? 17:47
emmanuel yes we concluded two interfaces 17:48
emmanuel one "controler" and one "dialect" 17:48
emmanuel I'll explore that next week
{quote}
> Abstract GridDialect from Infinispan's Cache API
> ------------------------------------------------
>
> Key: OGM-79
> URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-79
> Project: Hibernate OGM
> Issue Type: New Feature
> Components: core
> Affects Versions: 3.0.0.Alpha2
> Reporter: Emmanuel Bernard
> Fix For: 3.0-next
>
>
> See the discussion on this thread http://www.mailinglistarchive.com/html/hibernate-dev@lists.jboss.org/2011-05/msg00022.html
> and specifically this message http://www.mailinglistarchive.com/html/hibernate-dev@lists.jboss.org/2011-05/msg00044.html
> I think Datastore is the best we have so far
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list