Re: many instances of Shark in one VM

David Forslund <[email protected]>
Newsgroups gmane.comp.java.enhydra.shark
Message-ID <[email protected]>
Sounds like the classloader approach is the easiest.  You might want to 
separate out the configuration files from the war
file to make configuration a little easier, but you have to do something 
special for each client anyway.

The SharkCORBA may not be as difficult as you assume. If you are using 
the SharkJSPClient, I've created a similar
SharkJSPClient using the CORBA interfaces.  The code differences are 
pretty minor.  I would be happy to submit
this to the Shark code repository, but I do have some dependencies on 
some other small enabling libraries (for convenience) from
our OpenEMed code that would need to be removed.   But the module is 
available from our OpenEMed CVS repository as modules/WorkFlow
if you want to check it out.  There may be many other reasons you don't 
want to go that route, however.  It still may require providing
a separation in user space between the various clients unless you truly 
run a separate CORBA service for each client.   The advantage of the
latter, is that as long as the API remains stable, you can upgrade Shark 
on the server side without touching your web application.

Dave


Roshan wrote:

>Thanks Dave and Vladimir,
>
>        So far, we have the following options.
>1. Run a different instance of JBoss/Shark(thus, also a new JVM) for
>each client. Not the best solution though.
>
>2. Modify Shark code to allow multiple instances of the Shark engine in
>the same JVM. This means changing all singletons to return multiple
>instances and also to replace all static fields with instance fields in
>the entire Shark code/impl classes(Is this correct?). Though I have not
>read enough Shark code to say for sure, this may be a herculean task and
>may not even be successful. (Sasa, am I right?) 
>
>3. Use different classloaders as Vladimir pointed out. This seems to be
>a good/viable solution. However, instead of just creating and loading a
>new Shark.conf for each engine instance I will have to create a new
>war/ear for each client. Also a maintenance headache when we have to
>update code. (Anyone have any suggestions about multiple classloaders?)
>
>4. Try using SharkCorba server as Dave suggested, but this would be the
>last option as we would have to rework everything we have now.
>
>Thanks a lot for all the help,
>Roshan.    
>
>
>On Tue, 2005-07-05 at 18:02, Vladimir Puskas wrote:
>  
>
>>Hello Roshan
>>
>>you wrote:
>>    
>>
>>>Hi Sasa and others,
>>>
>>>      Is it possible to have many instances of Shark in a single Java VM
>>>or in JBoss? We are currently running one instance of Shark as a POJO
>>>library with session bean wrappers in JBoss. 
>>>
>>>      We are looking at providing BPM(using Shark) as a hosted service
>>>to some of our clients. We'd like to have a different instance of Shark
>>>(ie. one Shark and database instance per client) for security reasons
>>>and also to separate the repositories etc. for each client. Running a
>>>separate JVM/JBoss for each instance may be too expensive and not
>>>scalable(?). 
>>>
>>>     Shark does not allow you to configure more than one instance at a
>>>time ('Trying to configure shark instance that is already configured
>>>!!!'). Is there a way to start multiple instances, each with its own
>>>configuration(ie. different Shark.conf)? In org.enhydra.shark.Shark, we
>>>could make some changes to enable multiple instances, but it seems that
>>>such a change would also have to be made in other classes such as
>>>SharkEngineManager etc. 
>>>	Clustering is also another concern for such a system.
>>>
>>>     Tips and suggestions are welcome from everyone.
>>>      
>>>
>>AFAIK it's possible to achieve this using separate class-loaders, as in
>>webapp class-loaders division. You should be able to have multiple
>>JSPClient applications inside one web server. I've just confirmed this 
>>by deploying sharkworklisthandler.war twice in Enhydra6.3(Tomcat5.5).
>>
>>hope this helps
>>    
>>
>
>  
>
message.footer (text/plain, 271 B)
--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.