to occur during down times. Running on MySQL *might* be a problem for
us since it's not currently an endorsed DB provider (despite the site
being a Sun Microsystems Centre of Excellence and MySQL being owned by
Sun). But we're working on that...
That was just a suggestion - there's nothing currently in our
JDBCProvider that would prevent you from plugging any db - it's just
that the initialization script is currently tuned only for HSQLDB. I
simply haven't had the interest to tune other libraries in yet.
On the question of developing a sub-interface of JCR-170 as a
"guarantee of service", is that a possibility? While designed
as according to JSR-170 Priha is currently non-conformant (so
far as I understand) with the API, so wouldn't it be prudent
to create a sub-interface? Or am I not understanding the
situation? (possible, I've not had much time to get my head
around this yet)
I can't currently think any way that would make this approach
feasible. But JCR does define an
UnsupportedRepositoryOperationException, as well as feature discovery
so you can get runtime notification of what is possible and what is not.
This would suggest that a large number of document nodes (e.g.,
500,000),
might be a problem, i.e., if we didn't store them flat. Another
possibility
is to
Buckets.
root node / hash1 / hash2 / session id / document node
where hash1 = three first bytes from session id, hash2 = three next
bytes from session id
That way you will have max 2048 nodes under each bucket. This means
you can do 8 billion sessions with a trivial conversion
function :-). Adjust bucket sizes according to your need...
(Actually, this discussion would be better run on the priha-dev list)
/Janne
