Mise en veille prolongée solution paresseuse. Est ce bien?
-
16-09-2019 - |
Question
J'utilise l'approche suivante pour résoudre le problème d'initialisation paresseux en veille prolongée. S'il vous plaît me dire si cela fonctionnera ou non. Je dois mettre en œuvre mon transcation dans ma couche de persistence compulsary en raison de certaines raisons.
public class CourseDAO {
Session session = null;
public CourseDAO() {
session = HibernateUtil.getSessionFactory().getCurrentSession();
}
public Course findByID(int cid) {
Course crc = null;
Transaction tx = null;
try {
tx = session.beginTransaction();
Query q = session.createQuery(
"from Course as course where course.cid = "+cid+" "
);
crc = (Course) q.uniqueResult();
//note that i am not commiting my transcation here.
//Because If i do that i will not be able to do lazy fetch
}
catch (HibernateException e) {
e.printStackTrace();
tx.rollback();
throw new DataAccessLayerException(e);
}
finally {
return crc;
}
}
}
et dans le filtre je suis en utilisant le code folling
session = HibernateUtil.getSessionFactory().getCurrentSession();
if(session.isOpen())
session.getTransaction().commit();
Est-ce droit d'approche? Peut-il peut avoir un problème.
La solution
Assurez-vous que vous vous engagez toujours ou rollback puis toujours fermer votre session. En gros, vos ressources (transaction et session) devraient être libérés, peu importe ce que, par exemple ils peuvent être placés à l'intérieur de bloc finally approprié (en cas de session) ou dans les deux blocs essayer de capture (en cas de transaction).
En général, l'allocation et la libération des ressources entre les différentes couches d'application est anti-modèle - si vos forces d'architecture vous dans l'application anti-modèle alors il y a plus de questions à poser ici ... Par exemple, pensez à ce que vous devriez faire dans votre « filtre » si la session arrive à fermer ...