Modularity - osgi and data

I am busy with R&D with osgi and its role in the technology stack. I buy into the whole modularity and benefits this gives from a software component standpoint. Now, what I am battling to get my head around is the practical elements of the following statement

"An interesting feature of OSGi is multiple versions of a bundle can be deployed to the same container. All the bundles deployed in an OSGi container run in one JVM"

This is ideal and really truly a requirement for me, however in practical terms is this even feasible if we speak about software components managing data. So it makes sense to have multiple versions of a bundle deployed (or at least backward 开发者_高级运维compatible versions) but if that component is managing data or a resource..what are we saying are the implications to the data and resource layer. Do they equally have to have multiple and cohesive versions of themselves simultaneously in the container. If 2 bundles exist where they are minor versions, but there was a significant constraint imposed on the resource/data layer imposed in the 2nd bundle data schema...wouldn't this pose a problem.

My question is how far can this really go. Is it a case of ensuring we always have the 1 of the major bundles deployed and look to having minors co-exist in parallel. I am concerned that there is attention paid to the actual physical jar bundle itself...but no attention paid to the actual data/resource is has mandate over.

Anyone come across this dilemma before?

It depends what the bundles does as to whether having 2 versions side-by-side is practical. For example 2 versions of an XML parser is OK. But 2 version of SWT (in Eclipse) is not ok since SWT manages the display resource. This is why some bundles are marked as singletons to indicate the manage some single resource.