There is not the one correct answer to your question. It very much
depends how your application uses jackrabbit.
Here are some general considerations that might help you to decide which
way you want to go:
Pros for a single workspace:
- it is certainly easier to use by your application, you don't have to
login to multiple workspaces and fiddle with multiple sessions.
- less resource intensive. using one workspace will connect to a single
backend store (e.g. database). It will only create two indexes (one for
the workspace and one for the jcr:system tree) -> less open file handles.
Pros for using multiple workspaces:
- better concurrency when you have a lot of write operations that can be
distributed to multiple workspaces.
- increased cache efficiency. each workspace has its own cache that is
separated from others.
- allows you to use specific persistence manager implementations per
workspace that are tailored to the usage of that workspace.
regards
marcel
Mark Slater wrote:
Is there a performance benefit or hit to splitting a repository into
multiple workspaces?
The design I'm considering will create one workspace for each user's
"owned" data, and several "shared" data workspaces more directly managed
by the system. On the other hand, it would be a little easier for me to
code a single workspace design so if there's no difference, that's
probably better for me right now. But if Jackrabbit's performance is
better when data is split over multiple workspaces, I'd spend the extra
time on it. A lot of my app's data, including collections of larger data
files (1-10 MB each) are going to be stored in the Jackrabbit repository
so I'm a little concerned about performance there.
Mark
