[Biojava-dev] Why BJ3 should be multithreaded

[Andy Yates]

That is an interesting bit of usage. You could queue the events out from 
the feature builders into the thread/callable which constructs the final 
Sequence object quite easily. Yeah very very true :)

The majority of objects are mutable in BJ I think. I'm not saying this 
is a bad thing nor suggesting everything needs to be immutable :). It's 
more about making sure only one thread is working on one object at a 
given point in the program. If there are going to be mutable objects 
hanging around then Queues are probably the best way to work with them.

Andy

> 
> One area where you could get an interesting mixture of stateless and 
> synchronized access to a mutable would be threaded parsing of large 
> sequence files.  In my experience the BioJava parsers are not
> normally I/O bound due to all the object building they do.  Given
> this a filereader could for example read a feature block and hand it
> off to a threaded stateless feature handler which produces a Feature
> object and then adds it (synchronized) to the BioJava Sequence that
> is being built. As long as I/O doesn't limit then you would get
> improved parsing performance.  It would also be a case where the
> threading should happen internally as it could be pretty hard to
> coordinate the process from the outside.
> 
> This also highlights the difference between encapsulation and 
> immutability. Even if access to variables is controlled by package
> and protected setters the class is still mutable (but not by the
> user). Immutability can only be achieved by not providing any setter
> methods which has obvious severe limitations.  Currently BioJava
> Sequence objects have restricted mutability (use of Edit objects) but
> are certainly not immutable.
> 
> Again messages need not be immutable as long as they have appropriate
>  locks and or synchronized getters and setters.  Many java frameworks
>  work best when messages or DTO's are beans (with parameterless 
> constructors and public getters and setters), being able to use these
>  is often very desirable. These beans can still be threadsafe if you 
> code them right.
> 
> - Mark