Az SQL Server 2014-es memóriatáblákat csak akkor lehet a lehető legközvetlenebb módon elérni, ha natív kódra fordított tárolt eljárásokkal érjük el. Az OR mapperek viszont alapban sima, dinamikus SQL-eket generálnak. Ha így akarunk CRUD műveleteket végrehajtani egy memória táblán, akkor az átmegy a szerver interop rétegén, ami jelentősen belassítja azt. Többszörösére. Emiatt -jelen tudásom szerin-, ha OR mapperel akarjuk meghajtani a memória táblákat, akkor saját spket kell írni. Kipróbáltam a dolgot, de falakba ütköztem. Ugyanis az OR mapperek elvárják, hogy pl. egy update után visszaadja a szerver az xxx rows affected information message-et, ebből tudja az OR mapper, hogy sikerült a sor módosítása. Ha nem jön vissza semmi, akkor azt hiszi, hogy az optimista konkurencia ellenőrzés miatt nem sikerült a sor módosítása (azt hiszi valaki közben módosította vagy törölte a sort), így exceptiont dob. Viszont a memória táblás update NEM adott vissza XXX rows affected üzenetet, így az OR mapper exceptiont dob (NHibernate.StaleObjectStateException és ).
A megoldás tehát valószínűleg az lehet, hogy ki kell kapcsolni az OR mapper optimista konkurrencia ellenőrzőjét.
Egyelőre NHibernate-nél nem találtam megoldást rá, legalábbis a Conf ORM-es “code first” mapping módszerrel. EF-en még nem próbáltam.
Mindenesetre kiírtam msékhez a kérdést, ha jön válasz, megírom.

Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.