"Workspace.clone" is a workspace-write method, which means it works only against the persisted state and immediately performs the operation and persists it. Therefore, it cannot see transient state within sessions. See Section 10.1.5.2 in the JSR-283 specification for a list of all workspace-write methods.
Simple move the "session.save()" before the "ws.clone(...)" call.
BTW, even moving the "session.save()" before the "ws.clone(...)" call probably doesn't work in 3.1.3.Final or earlier within a single CMT (or any user transaction) because of MODE-1822, which has been fixed in 'master' and will be available in 3.2.
Thanks, I verified if /a already exists the clone() succeeds, but if it is created in the same session it fails (even with the save() before the clone() since I'm running 3.1.2). Will be looking forward to the fix in 3.2. In the mean time, I'll see if separate BMT transactions can be used as a workaround.
I don't think BMT will work, either. MODE-1822 covered all external transactions.
Thanks. I will wait to use shared nodes until 3.2.
I am just starting to investigate their use and am wondering if there are any best practices or rules of thumb? For example, I am tracking digital video files, so I have a node containing information about the file. The video information node can logically appear in multiple paths - in a heirarchy organized by title, date, genre, etc. They may also appear in a user's "my videos" folder. Is this a "good" use of shared nodes - it seems to be what they were intended for. So far I have been using references, but I'm starting to end up with circular reference paths so I am thinking that shared nodes may be a better design.