Hi,
The main problem seems to be:
- Avoid blocking the engine when streaming large objects
I could write a test with multiple sessions that concurrently read and
write large and small objects. Like this we have something to test
against. Or does such a test already exist?
Afterwards, I would
Hi,
On 6/14/07, Thomas Mueller [EMAIL PROTECTED] wrote:
I think it is. But it is not very important to decide what garbage
collection algorithm to use at this stage. It is still possible to
switch the algorithm later on. OK it is a bit more work.
ACK, we can get back to that when we have some
Hi,
On 6/15/07, Thomas Mueller [EMAIL PROTECTED] wrote:
The main problem seems to be:
- Avoid blocking the engine when streaming large objects
I could write a test with multiple sessions that concurrently read and
write large and small objects. Like this we have something to test
against. Or
Hi,
On 6/13/07, Thomas Mueller [EMAIL PROTECTED] wrote:
I just read about the Global Data Store proposal
(https://issues.apache.org/jira/browse/JCR-926) and I think it's a
great idea:
Thanks. :-)
However I am not sure if mark-and-sweep garbage collection (GC) is the
best solution:
- Very
Hi,
mark-and-sweep garbage
I agree that it's slow and late, but I don't think either is a big
problem.
I think it is. But it is not very important to decide what garbage
collection algorithm to use at this stage. It is still possible to
switch the algorithm later on. OK it is a bit more work.
Hi,
I just read about the Global Data Store proposal
(https://issues.apache.org/jira/browse/JCR-926) and I think it's a
great idea:
- Avoid blocking the engine when streaming large objects
- Avoid copying twice (first transient, then persistent store)
- Versioning: avoid multiple copies of the
hi jukka,
On 6/5/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 5/16/07, Jukka Zitting [EMAIL PROTECTED] wrote:
On 5/12/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Based on the feedback I agree that it probably doesn't make sense to
keep track of unique copies of all values. However,
Hi,
On 6/6/07, Stefan Guggisberg [EMAIL PROTECTED] wrote:
is there a way to purge the binary store, i.e. remove unreferenced data?
i am a bit concerned that doing a lot of add/remove operations would
quickly exhaust available storage space. at least we need a concept
how deal with this kind of
On 6/6/07, Stefan Guggisberg [EMAIL PROTECTED] wrote:
hi jukka,
On 6/5/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 5/16/07, Jukka Zitting [EMAIL PROTECTED] wrote:
On 5/12/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Based on the feedback I agree that it probably doesn't make sense
Hi,
On 6/6/07, Stefan Guggisberg [EMAIL PROTECTED] wrote:
something that just crossed my mind: i know a number of people
want to store everything (config, meta data, binaries and content)
in the same db in order to allow easy backup/restore of an entire
repository. currently they can do so by
Hi,
On 5/16/07, Jukka Zitting [EMAIL PROTECTED] wrote:
On 5/12/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Based on the feedback I agree that it probably doesn't make sense to
keep track of unique copies of all values. However, avoiding extra
copies of large binaries is still a very nice
Hi,
Thanks for the comments so far on this topic! I've been thinking about
this a bit more and I now have the second iteration ready for review.
Read on...
Based on the feedback I agree that it probably doesn't make sense to
keep track of unique copies of all values. However, avoiding extra
A value record would essentially be an array of bytes as defined in
Value.getStream(). In other words the integer value 123 and the string
value 123 would both be stored in the same value record. More
specific typing information would be indicated in the property record
that refers to
Alex,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
I may be misreading something, but my main concern with this approach
is that while minimizing the size of the storage (which is very cheap
right now and almost infinite) it has a penalty on the access
performance: needing 2 I/O
On 4/28/07, Miro Walker [EMAIL PROTECTED] wrote:
Alex,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
I may be misreading something, but my main concern with this approach
is that while minimizing the size of the storage (which is very cheap
right now and almost infinite) it has a
On 4/25/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
On 4/23/07, Jukka Zitting [EMAIL PROTECTED] wrote:
My idea is to store each value in a unique and immutable value
record identified by a value identifier. Duplicate values are
Hi,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
Another possible problem with the shared values approach is that in a
concurrent environment accessing these may become a bottleneck as you
will almost always need to serialize the access. Considering that
reading is now a 2 step op
On 4/25/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
Another possible problem with the shared values approach is that in a
concurrent environment accessing these may become a bottleneck as you
will almost always need to serialize the
On 4/25/07, Torgeir Veimo [EMAIL PROTECTED] wrote:
On 25 Apr 2007, at 14:18, Alexandru Popescu ☀ wrote:
I see. Now my next question is: how do you clean behind? If a value
becomes unreferenced will you or will you not clear it?
Isn't the purpose of a versioned repository to keep all old
Hi,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
I see. Now my next question is: how do you clean behind? If a value
becomes unreferenced will you or will you not clear it?
It won't be cleared unless the repository gets explicitly recreated
using some vacuuming process. I don't
Hi,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
On 4/25/07, Jukka Zitting [EMAIL PROTECTED] wrote:
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
I see. Now my next question is: how do you clean behind? If a value
becomes unreferenced will you or will you not clear
Hi,
On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote:
Yes, it is. But not all content is versionable. Is this proposal only
for versionable content? If so, I apologize as I have missed this
part.
The proposal is for all content, but internally it actually keeps full
change histories of
I've been reading this thread with interest - and one thing I wanted
to comment on about keeping full version history, and not cleaning up
any data, this sounds like a good way to allow for anyone to take a
snapshot of the repository at any period of time from it's creation
and get an
hi jukka,
i am very much in favor of such an approach.
My idea is to store each value in a unique and immutable value
record identified by a value identifier. Duplicate values are only
stored once in a single value record. This saves space especially when
storing multiple copies of large
Hi,
On 4/24/07, David Nuescheler [EMAIL PROTECTED] wrote:
A value record would essentially be an array of bytes as defined in
Value.getStream(). In other words the integer value 123 and the string
value 123 would both be stored in the same value record. More
specific typing information
Jukka Zitting wrote:
Hi,
I started prototyping the next generation persistence proposal
discussed before, and would like feedback on an idea on how to store
values in this persistence model.
My idea is to store each value in a unique and immutable value
record identified by a value identifier.
Hi,
I started prototyping the next generation persistence proposal
discussed before, and would like feedback on an idea on how to store
values in this persistence model.
My idea is to store each value in a unique and immutable value
record identified by a value identifier. Duplicate values are
27 matches
Mail list logo
