Hi Tom, thanks for the info!
On 17/01/07, Tom De Mulder <[EMAIL PROTECTED]> wrote:
> I wish you'd either get rid of the object cache or use an open source
> cache implementation. However, given the nature of DSpace (and the fact
> that most of the time you won't get the same item being accessed quickly
> in succession) I don't think it needs an object cache. And, as I just
> said, disabling it makes it *faster*.
The object cache is more for consistency problems where the same
object (e.g. an Item) is instantiated twice, e.g.
Item i1 = Item.find(context, 123);
i.addDC("dc", "description", "abstract");
...elsewhere in same transaction
Item i2 = Item.find(context, 123);
i1.update();
Now i1 and i2 are out of sync and changes may be overwritten. This
was a problem we ran into pre-1.0 -- there was some weird UI behaviour
where Items were not being updated in DB correctly. The object cache
was added as a reactive measure to fix this, not a preemptive one. So
before switching it off in the DSpace code I'd prefer that some
testing, particularly of the submit + workflow steps be done lest we
reintroduce some very old bugs.
A better (but more labour intensive) route to a performance increase
is probably to use this object cache only for operations involving a
write. The vast majority of DSpace Contexts will be read-only. So
most operations could use a ReadOnlyContext (you'd need to know a
priori if a write operation will occur but you should know this based
on e.g. what servlet you are). That would also mean we could get rid
of the connection.commit()/abort() that happens in every read-only
Context which has always made me wince a little. Only the "writing"
contexts would need an object cache, and these are the minority.
Then a more flexible "global" object cache could be used for read only
operations, prob based as you suggest on a 3rd party solution.
> Another issue is backups - when you have as many files as we do, it gets
> hard to find out what's changed in the assetstore when making backups (we
> use rsync so we can backup only the changes - copying the entire
> assetstore across each time would be too much of a hit, even on our
> dedicated network link to our offsite backup servers).
If we added modification dates to bitstreams and some utility to list
those changes since a date, would that help?
As for authz, it's waiting for someone to step up and take it on...
volunteers please form an orderly queue...
Rob
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
