[Building Sakai] has anyone seen one of these before? hibernate cache death.

Steve Swinsburg steve.swinsburg at gmail.com
Mon Dec 10 14:38:18 PST 2012


If I'm reading the old thread correctly, Ian was talking about a webapp war, not a component war:
http://old.nabble.com/has-anyone-seen-one-of-these-before--hibernate-cache-death.-td9054857.html

Grepping for hibernate in the deployed webapp finds several references to hibernate, there are no deployed jars though:

[steveimac:~/dev/sakai/tomcat/trunk/webapps]$ find . -name hibernate\*
[steveimac:~/dev/sakai/tomcat/trunk/webapps]$

cheers,
Steve




On 11/12/2012, at 3:25 AM, Jim Eng <jimeng at umich.edu> wrote:

> I have found only one hibernate jar among the artifacts deployed for this sakai instance (basically a trunk build from a month or so ago with some additional contrib projects and ctools-specific projects).  That is here:
> 
> 	shared/lib/hibernate-3.2.7.ga.jar
> 
> The other interpretation I thought of for Ian's message is that in some project some code is using a static hibernate method to get a session factory instead of getting it from the component manager.  I may have done that myself at some time.  Is that the meaning?  
> 
> Appreciate any advice anybody can give.  
> 
> Thanks.
> 
> Jim
> 
> 
> On Dec 10, 2012, at 10:21 AM, Jim Eng wrote:
> 
>> 
>> Ian:  This is reaching back to ancient times for you, I'm sure, but you gave
>> the following advice five years ago.  I'm not sure I understand correctly,
>> but it seems like the second paragraph may be saying that a hibernate jar is
>> being deployed in some sakai component war instead of having that component
>> rely on a common hibernate jar.  If that's the case, would it make sense to
>> try to find the culprit by looking for a hibernate jar in a component war
>> and then revising the poms for that project to avoid including the hibernate
>> jar in the war? Would it make sense to think the cause of this must be a
>> contrib or local project rather than part of sakai's kernel or core because
>> otherwise it would be a common problem?
>> 
>> 
>> 
>> Ian Boston-2 wrote:
>>> 
>>> This is caused the ehcache singleton being bound to in a war and that 
>>> war being reloaded.
>>> 
>>> Its often caused by having a Hibernate Session factory inside the war 
>>> rather than in components or a secondary use of ehcache.
>>> 
>>> The really nasty thing about this, is that you may not get the error 
>>> message until some point after the suspect war has reloaded as it 
>>> doesn't happen until one of the consumers of ehcache tries to access a 
>>> stale copy of ehcache.
>>> 
>> 
>> -- 
>> View this message in context: http://old.nabble.com/has-anyone-seen-one-of-these-before--hibernate-cache-death.-tp9054857p34779895.html
>> Sent from the Sakai - Development mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"



More information about the sakai-dev mailing list