[Mulgara-dev] adding ResolverFactoryInitializer.getSessionFactory()

[Andrae Muys]

On 19/05/2008, at 11:44 AM, Life is hard, and then you die wrote:
> On Mon, May 19, 2008 at 11:36:40AM +1000, Andrae Muys wrote:
> [snip - I'll answer the rest later]
>>>> On 18/05/2008, at 3:26 PM, Life is hard, and then you die wrote:
> [snip]
>>>>> There's currently no way (that I can see) for a resolver to get a
>>>>> handle on the "current" SessionFactory (the one it belongs to);
>>>>> so I'm
>>>>> thinking of adding a getSessionFactory() to the
>>>>> ResolverFactoryInitializer to get that functionality - does  
>>>>> anybody
>>>>> have any reservations or reasons not to do this? Or any better
>>>>> suggestions?
> [snip]
>> So back to the original problem: Just use a LocalSessionFactory and
>> connect from within the resolver as if you were a normal embedded
>> client.  No need to use RMI, just make sure you access it from a
>> different thread to the one that invoked the resolver.
>
> No, already tried that. The client's are using RMI to talk to mulgara,
> so they get an RmiSessionFactory. If I now get a LocalSessionFactory
> then I get the following error:
>
> ...
> caused by: org.mulgara.server.SessionFactoryException: Could not  
> instantiate TripleStoreImplementation from configuration.
>         at  
> org.mulgara.server.SessionFactoryFactory.getTripleStoreImplementation( 
> SessionFactoryFactory.java:180)
>         at  
> org.mulgara.server.SessionFactoryFactory.newSessionFactory 
> (SessionFactoryFactory.java:227)
>         at org.mulgara.server.local.LocalSessionFactory.newSession 
> (LocalSessionFactory.java:195)
>         ... 22 more
> Caused by: java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0 
> (Native Method)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance 
> (NativeConstructorAccessorImpl.java:39)
>         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance 
> (DelegatingConstructorAccessorImpl.java:27)
>         at java.lang.reflect.Constructor.newInstance 
> (Constructor.java:494)
>         at  
> org.mulgara.server.SessionFactoryFactory.getTripleStoreImplementation( 
> SessionFactoryFactory.java:176)
>         ... 24 more
> Caused by: org.mulgara.store.nodepool.NodePoolException: Couldn't  
> construct node pool
>         at  
> org.mulgara.store.nodepool.xa.XANodePoolFactory.newNodePool 
> (XANodePoolFactory.java:129)
>         at org.mulgara.resolver.StringPoolSessionFactory.<init> 
> (StringPoolSessionFactory.java:135)
>         at org.mulgara.resolver.Database.<init>(Database.java:582)
>         at org.mulgara.resolver.Database.<init>(Database.java:320)
>         ... 29 more
> Caused by: java.io.IOException: Lock file busy (internal): /mnt/ 
> ramdisk/topazproject/xaNodePool/xa.np.lock
>         at org.mulgara.store.xa.LockFile.lockInternal(LockFile.java: 
> 152)
>         at org.mulgara.store.xa.LockFile.<init>(LockFile.java:96)
>         at org.mulgara.store.xa.LockFile.createLockFile 
> (LockFile.java:138)
>         at org.mulgara.store.xa.LockFile.createLockFile 
> (LockFile.java:124)
>         at org.mulgara.store.nodepool.xa.XANodePoolImpl.<init> 
> (XANodePoolImpl.java:207)
>         at  
> org.mulgara.store.nodepool.xa.XANodePoolFactory.newNodePool 
> (XANodePoolFactory.java:125)
>         ... 32 more
>
> Mulgara has a bunch of singletons down in the statement store and node
> pool, and attempting to use two different session-factories results in
> two different Database instances which doesn't work...

Arrrrgh, Bugger.  Let me assure you, if ever I run a software  
company, I'm inclined to make use of Singleton cause for summary  
dismissal!  I hate that pattern!

Were you able to identify the singleton culprit in this instance?   
And if so, do you think it is feasible to put it out of our misery?

Andrae

--
Andrae Muys
andrae at netymon.com
Senior RDF/Semantic-Web Consultant
Netymon Pty Ltd