[
https://issues.apache.org/jira/browse/IGNITE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391447#comment-15391447
]
Vladimir Ozerov edited comment on IGNITE-1915 at 7/25/16 7:10 AM:
------------------------------------------------------------------
Pavel, my comments:
1) Passing only cache name looks wrong to me. There many dozens configuration
properties user might want to set for cache, but you always end up with
PARTITIONED/TRANSACTIONAL cache. You should have a ctor which will accept
normal configuration or reference to this cache config in Ignite config XSD.
2) Having default cache name looks wrong to me either. What if user has a
single cluster which is going to work with multiple databases? In this case by
default you will mix data from different databases.
3) Having cache-for-cache with {{double}} key looks dangerous to me because
{{double}} and {{float}} are not precise types. Can we use {{long}} instead?
4) It is not clear how OPTIMISTIC/REPEATABLE_READ transaction modes were
choosen. If you decide to use optimistic transactions, then at least you should
handle possible optimistic update exception somehow.
5) Dependency sets are not sorted, so deadlocks are possible.
6) Instead of getting all keys for entity set and then attaching a new key (GET
-> PUT), it is better to use entry processors. This will minimize amount of
network trips.
7) If you implement p.6 most probably you will not need transactions at all, as
you can simply update entity sets through entry processor one by one.
8) What if key value will be equal to entity set name? Looks like it will brake
provider. Probably you should have two caches: data cache for keys and metadata
cache for entity sets. We handle IGFS in this way. Moreover, you may want to
have different setting for these cafches. E.g. you may want to store data in
PARTITIONED cache to distribute load, but store metadata in REPLICATED cache
because it is mostly-read and rarely updated.
was (Author: vozerov):
Pavel, my comments:
1) Passing only cache name looks wrong to me. There many dozens configuration
properties user might want to set for cache, but you always end up with
PARTITIONED/TRANSACTIONAL cache. You should have a ctor which will accept
normal configuration or reference to this cache config in Ignite config XSD.
2) Having default cache name looks wrong to me either. What if user has a
single cluster which is going to work with multiple databases? In this case by
default you will mix data from different databases.
3) Having cache-for-cache with {{double}} key looks dangerous to me because
{double}} and {{float}} are not precise types. Can we use {{long}} instead?
4) It is not clear how OPTIMISTIC/REPEATABLE_READ transaction modes were
choosen. If you decide to use optimistic transactions, then at least you should
handle possible optimistic update exception somehow.
5) Dependency sets are not sorted, so deadlocks are possible.
6) Instead of getting all keys for entity set and then attaching a new key (GET
-> PUT), it is better to use entry processors. This will minimize amount of
network trips.
7) If you implement p.6 most probably you will not need transactions at all, as
you can simply update entity sets through entry processor one by one.
8) What if key value will be equal to entity set name? Looks like it will brake
provider. Probably you should have two caches: data cache for keys and metadata
cache for entity sets. We handle IGFS in this way. Moreover, you may want to
have different setting for these cafches. E.g. you may want to store data in
PARTITIONED cache to distribute load, but store metadata in REPLICATED cache
because it is mostly-read and rarely updated.
> .NET: Ignite as Entity Framework Second-Level Cache
> ---------------------------------------------------
>
> Key: IGNITE-1915
> URL: https://issues.apache.org/jira/browse/IGNITE-1915
> Project: Ignite
> Issue Type: Task
> Components: platforms
> Affects Versions: 1.1.4
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Labels: roadmap
> Fix For: 1.7
>
>
> Entity Framework is #1 ORM for .NET
> We should provide easy solution to boost Entity Framework performance with
> Ignite.
> EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in
> one, EF6 requies more customization or a 3rd party lib like
> https://efcache.codeplex.com/). For now, let's do EF6 only.
> This should be in a separate assembly and a separate NuGet package.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
