Hej,
I've found out that it doesn't depend on the way how transactions are used (retrieval
and delete in own transactions, retrieval in no transaction, retrieval and deletion in
same transaction). The problem is the following. I've got this resource tree in the
Slide repository:
files/
+ editorial/
+ test.txt
I read the content stream of "test.txt". When I delete "test.txt" right afterwards with the Macro helper,
then this deletion can be performed. But removal of the parent collection "editorial" produces the error
(independent of if "test.txt" still exists or was removed by the Macro.remove() before).
Stefan
Am Fri, 13 Aug 2004 14:17:36 +0200 schrieb Oliver Zeigermann <[EMAIL PROTECTED]>:
Stefan Fromm wrote:
Hello,
I try to get the content stream of a resource. This happens NOT inside a transaction
with these statements:
String uri = ...;
NodeRevisionDescriptors revisions = content.retrieve(slideToken, uri);
NodeRevisionDescriptor revision = content.retrieve(slideToken, revisions);
NodeRevisionContent revisionContent = content.retrieve(slideToken, revisions,
revision);
return revisionContent.streamContent();
This delivers the content stream as expected. It can be read successfully. After
having used the InputStream it is closed by calling its close() method. Then there
follows a Macro.remove(...) inside a transaction which includes the resource to be
deleted. I receive the error attached at the end after - as it seems - a timeout.
It seems to me that Slide cannot acquire a lock on a resource to delete. Does getting the input stream lock the resource? And how to release the lock? If this is the problem...
Retrieving the revision content acquires a lock on the resource. It should be
released when the input stream gets closed. Judging from the stack trace I'd say the
read lock has not been released. Are you very sure that you actually close the input
stream? If so, maybe it might be a bug in Slide. This, however, would surprise me as
the stuff above is done all the time.
Try running the above retrieval either in a transaction of its own or inside the same
transaction as the remove. You should observe a different problem or none at all...
Please report back,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
