ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-1915) .NET: Ignite as Entity Framework Second-Level Cache
Date Mon, 25 Jul 2016 07:10:20 GMT

    [ 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)

Mime
View raw message