AnsweredAssumed Answered

Lingering node references

Question asked by petern on Nov 19, 2008
Latest reply on Jan 27, 2009 by kumbach
Hi all,
We have been developing a document repository using Alfresco and have come across two weird 'phantom node reference' issues. I would be grateful if anyone could shed some light no the matter or point out what it is that we've just totally overlooked in either case.

We have developed a custom action which is responsible for 'intelligently' moving or merging directories from one location in the repository ('inbox') to another location ('document store'). The specific logic isn't important, suffice to say that it will either
- Move the entire folder "Inbox > Foo" to "Document Store > Foo" if the latter does not exist.
- Move the *contents* of "Inbox > Foo" if "Document Store > Foo" does exist, which consists of moving all of the files from one to the other, renaming as necessary to avoid overwrites, leaving an empty folder "Inbox > Foo" which is then deleted.

The action can either be performed via the "Run Action" wizard, or by an inline link which shows up by folders in Space Browse view, along with Cut, Copy, Edit offline, etc. The action is a Java class extending ActionExecutorAbstractBase, with an evaluator and a bean class. It is registered as a managed bean so that the action links can call it, and the action links are configured and working.

If the action is performed by clicking the inline-link, you're returned to the space containing the node you actioned when the action finishes (that is to say, if you're at "Inbox" and you click the action link on node "Foo", the action runs and you are returned to "Inbox").

We have come across an issue whereby *sometimes*, in the case where the node is moved as opposed to deleted, we are returned to Inbox and our "Foo" node, which should have either been whisked off elsewhere, is still visible - thus making it theoretically possible to run the action again, as well as being a bit confusing for users. If we re-load the page the problem is solved. Other times this does not happen and the node is gone right away, as you would expect. The node (and all its children) are successfully moved to their destination in either case, and this leads me to believe it is an issue whereby the internal references Alfresco is using to generate the 'browse' page upon completion of the action are out of date. Finally, if the 'ghost' item's name is clicked we successfully navigate to it, albeit we are actually navigating to 'Document Store > Foo'
The wiki states:
By default, each invocation of a Service method is wrapped in its own transaction. This has been configured via Spring
Which I have not changed. This means I do not need to transact my actions as a whole either?

We are using the CIFS server, with a mapped network drive on a windows box pointed at the 'Inbox' folder. If we create a directory 'Foo' therein, everything is well and we can populate the dir with files, delete, etc.
However, if we remove that folder from within the web interface (cut/paste elsewhere, or delete) we run into more lingering-reference issues (removing the folder via CIFS works fine). Moving the folder from 'Inbox > Foo' to 'Somewhere > Foo' via the web interface (e.g. via the custom action above) does everything as expected as far as the webclient is concerned - looking in Inbox reveals no Foo folder (unless of course the above issue occurs too!). If we refresh the Explorer window pointing to the CIFS dir, then the folder will disappear from here too. However, it is still 'there'. Dragging or creating another folder with the same name in CIFS will create a folder point to wherever the other was moved to. This is a problem as it is possible a same-named folder could be require to be created often, and it is crucial that our actions/processing are not bypassed.
The first issue could feasibly by our fault, but the second one I'm not so sure about - it's reproducible using stock Alfresco actions, most notably delete.
Restarting Tomcat will clear the issue up - no ghost references in CIFS afterwards.

Any ideas? Is it just Alfresco being weird or are we doing something wrong?