konto usunięte

Temat: Cache Spring vs Cache Hibernate , Transactional

Witam, nie mam dużej wiedzy jeśli chodzi o Springa.
Mam kilka pytań
1 - W jaki sposób najlepiej cachować zapytania ? Uzywać do tego co nam daje Spring - @Cacheable and @CacheEvict, czy 2nd Level Hibernate?

2 - Co do transakcji
Jeśli mam metodę, która nie modyfikuje żadnych danyh w BD, jedynie pobiera je , musi być ona w transakcji ?

3 - Ja używam w warstwie Service adnotacji - @Transactional, @Cacheable - czy lepiej przenieść je do DAO ?

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p" xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:cache="http://www.springframework.org/schema/cache"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.0.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc-4.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd
">


<context:annotation-config />
<tx:annotation-driven />
<cache:annotation-driven/>


<context:component-scan base-package="com">
<context:exclude-filter type="annotation"
expression="org.springframework.stereotype.Controller" />
</context:component-scan>


<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="jdbc:postgresql://localhost:5432/Test" />
<property name="username" value="postgres" />
<property name="password" value="blablavla" />


</bean>

<bean id="sessionFactory"
class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">

<property name="dataSource">
<ref bean="dataSource" />
</property>

<property name="hibernateProperties">
<props>
<prop key="hibernate.max_fetch_depth">5</prop>
<prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.hbm2ddl.auto">update</prop>
</props>
</property>
<property name="annotatedClasses">
<array>

<value>com.model.User</value>
<value>com.model.TableRestaurant</value>
<value>com.model.Reservation</value>
</array>

</property>

</bean>


<bean id="transactionManager"
class="org.springframework.orm.hibernate4.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory" />
</bean>


<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<!-- Definicja magazynu-->
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean">
<property name="name" value="tables"/>
</bean>
</set>
</property>
</bean>





</beans>



@Service
public class TableRestaurantServiceImpl implements TableRestaurantService {

@Autowired
private TableRestaurantDAO tableDAO;

@Override
@Transactional
@Cacheable("tables")
public List<TableRestaurant> listTables() {
// TODO Auto-generated method stub
return tableDAO.listTables();
}
@Override
@Transactional
@Cacheable("tables")
public List<TableRestaurant> avaibleTables() {
// TODO Auto-generated method stub
return tableDAO.avaibleTables();
}
@Override
@Transactional

public void bookTable(Long id) {
tableDAO.bookTable(id);

}
@Override
@Transactional
public void releaseTable(Long id) {
tableDAO.releaseTable(id);

}

}

konto usunięte

Temat: Cache Spring vs Cache Hibernate , Transactional

1. Generalnie - zależy. Cache Hibernate'a operuje na niższym poziomie... Jak masz sporo operacji, na paru warstwach, a do tego wynik jest mały? Na poziomie serwisu można zrobić cache i mieć pod ręką dane... Zależy - co jest potrzebne i co się sprawdza.

2. Z poziomu springa da się zrobić tak, żeby transakcji nie było. Dla Hibernate'a jest inaczej:
https://forum.hibernate.org/viewtopic.php?f=1&t=930167
Dla bazy danych jest +/- jak dla Hibernate'a. Jak się zrobi, żeby metoda miała transakcję read only nie będzie flusha na sesji hibernate'a.

3. Jak w 1. - zależy. Transactional na tym poziomie jest ok, bo np. nie trzeba robić eager... Cache - też - zależy. To, co mogę powiedzieć - nie ma sensu robić cache na kilku poziomach... Ja bym zprofilował oba rozwiązania i zobaczył co lepiej działa - na realnych danych.
Zbigniew Artemiuk

Zbigniew Artemiuk python/java or
java/python
developer

Temat: Cache Spring vs Cache Hibernate , Transactional

1. Cachownie to long story. 2nd level cache powoduje niezłe przyspieszenie więc ogólnie warto go używać. Kwestia czy rzeczywiście go potrzebujesz.

2. Transakcja (w sensie bazodanowym) jest zakładana na poziomie datasource'a przy każdym zapytaniu i po każdym jest commit (tryb autocommit). Jak włączysz transactionManagera to wyłącza on te autocommity na datasourcie (tak w przypadku TM na prostym JDBC [DataSourceTransactionManager]) i zaczyna sam nimi zarządzać w zależności od adnotacji @Transactional.
Dodatkowo jak masz Hibernate'a to pojawia ci się SessionFactory i sesje hibernatowe (wtedy zmienia sie TM) ale ogólne działanie TM jest takie samo.

3. Generalnie jak w metodzie service'u używasz jednej prostej operacji (np. read encji) i nie korzystasz później z lazy-loadingu na tych wyjętych encjach to @Transactional jest zbedne. Nie wiem jak dao masz zrobione ale wzorcowe dao (http://projects.spring.io/spring-data-jpa/) ma, tak jak mowi Michal, @Transactional(readOnly=true) na prostych operacjach czytających.
Jak w metodzie service'u masz wiele operacji na dao to wrappuje metode w @Transactional a dao jak ma @Transactional to (zgodnie z default propagation [REQUIRED] na @Transactional) będzie kontynować tę transakcję (lub ją założy jak jej nie ma).

Pytanie z innej beczki - z jakiego powodu twój serwis implementuje jakiś interfejs? To taki sztuczny interfejs?

konto usunięte

Temat: Cache Spring vs Cache Hibernate , Transactional

Zbigniew A.:
[...]
Co do cache. Pytanie na którym poziomie buforować. Można na fasadzie, czy tam na poziomie serwisów, można na DAO. Jak kilka serwisów korzysta z DAO - fajnie wyjdzie cache na DAO. Jak jest sporo logiki w serwisach - jest sens robić cache na wyższym poziomie. Dobrym kandydatem na cache są rzeczy często używane, a nie zmieniające się za często - np. dane użytkownika. Jak miałbym to sam robić... zrobił bym profilowanie - bez cache, potem z różnymi wariantami i optymalizował top 10 najwolniejszych...
Pytanie z innej beczki - z jakiego powodu twój serwis implementuje jakiś interfejs? To taki sztuczny interfejs?

Dokumentacja mówi, że w ten sposób jest ciut szybciej :D Chociaż zaraz obok jest dodane, że względy wydajnościowe nie powinny być brane pod uwagę przy takich decyzjach. Mając interfejs łatwiej zrobić stuba, albo innego mocka. Czasem, jak część funkcjonalności robi ktoś inny, a ja potrzebuję jednak mieć jakieś odpowiedzi? Dogadujemy interfejs, a potem każdy robi swój kawałek. Wiadomo, że nie jest to idealne rozwiązanie, ale da się zrównoleglić robotę.

konto usunięte

Temat: Cache Spring vs Cache Hibernate , Transactional

Interfejs czemu ? Wiem co dokładnie maja robić klasy .
Zbigniew Artemiuk

Zbigniew Artemiuk python/java or
java/python
developer

Temat: Cache Spring vs Cache Hibernate , Transactional

Wiem, ze używając springa często tworzy się sztuczne interfejsy. Jeżeli interfejs ma wyrażać jakiś kontrakt to ok, ale jeżeli tylko po to żeby spring miał "łatwiej" zakładać proxy (nie przez cgliba) i masz tylko 1 implementację tego interfejsu to nie ma to najmniejszego sensu. Dodatkowo te klasy z końcówką Impl to samo zło. Nawet w EJB odchodzi się od interfejsów.
Ja staram się tępić te sztuczne interfejsy bo wprowadzają totalny chaos. Co klasa ma robić wiadomo po klasie i po jej metodach ;-)
A co do mockowania to mockito radzi sobie bardzo dobrze i z klasami ;-)

konto usunięte

Temat: Cache Spring vs Cache Hibernate , Transactional

Zbigniew A.:
[...]
A co do mockowania to mockito radzi sobie bardzo dobrze i z klasami ;-)

W testach tak. Czasem potrzebuję czegoś, co działa w kodzie produkcyjnym. Tymczasowo, ale jednak jest. No, a wiadomo co można powiedzieć o prowizorkach :D

Odkąd są typy generyczne castowania nie trzeba robić i sporo takich protez się uprościło. Dziś nie ma to sensu. Lepiej pisać mniejsze klasy serwisowe, które delegują robotę dalej... Łatwiej to czytać.



Wyślij zaproszenie do