Enforcing constraints; Sessions and Threading

[Dan Diephouse]

Hi all,

This is probably a horrendously stupid question, but I'm hoping someone
can help me figure out how to enforce constraints nodes. I'm writing a
JCR store for Abdera to store Atom entries. I'm creating a node for each
entry and one of the properties on the node is the "resource name".
(I.e. what's in the HTTP URL - /my_entry.atom). I don't ever want to
have multiple nodes with the same resource name property. Whats the best
way to enforce this so I can never have two threads create the same
resource at the same time?

Also, can anyone point me to something which highlights how Sessions and
threads are supposed to work? Are sessions single threaded? Can they be
shared accross threads for reading? Should I pool them? Do I logout at
app shut down or when I'm done reading data (it seems the former).

- Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog

[Jukka Zitting]

Hi,

On 11/5/07, Dan Diephouse <[hidden email]> wrote:
> This is probably a horrendously stupid question, but I'm hoping someone
> can help me figure out how to enforce constraints nodes. I'm writing a
> JCR store for Abdera to store Atom entries. I'm creating a node for each
> entry and one of the properties on the node is the "resource name".
> (I.e. what's in the HTTP URL - /my_entry.atom). I don't ever want to
> have multiple nodes with the same resource name property. Whats the best
> way to enforce this so I can never have two threads create the same
> resource at the same time?

There's nothing like a UNIQUE constraint in JCR or Jackrabbit (though
it might be good to have at least a Jackrabbit feature request in Jira
for that), so the closest you can get probably to make the "resource
name" be the name of the entry node and have all the entries stored as
children of a parent node that doesn't allow same-name-siblings.

Alternatively you need to implement that constraint in your code.
Whenever creating a new node (or modifying the "resource name"
property) you could lock the subtree (or just a separate lock node)
and check that the constraint isn't being violated before saving the
changes.

> Also, can anyone point me to something which highlights how Sessions and
> threads are supposed to work? Are sessions single threaded? Can they be
> shared accross threads for reading? Should I pool them? Do I logout at
> app shut down or when I'm done reading data (it seems the former).

You should only access a Session from a single thread at a time.
There's some overhead to starting a new Session (and part of the
caching is Jackrabbit is session-bound), so if your application is
performance-sensitive then you may want to use a session pool.

BR,

Jukka Zitting

[Dan Diephouse]

Some javascript/style in this post has been disabled (why?)

Jukka Zitting wrote:

Hi,

On 11/5/07, Dan Diephouse [hidden email] wrote:
  

This is probably a horrendously stupid question, but I'm hoping someone
can help me figure out how to enforce constraints nodes. I'm writing a
JCR store for Abdera to store Atom entries. I'm creating a node for each
entry and one of the properties on the node is the "resource name".
(I.e. what's in the HTTP URL - /my_entry.atom). I don't ever want to
have multiple nodes with the same resource name property. Whats the best
way to enforce this so I can never have two threads create the same
resource at the same time?
    

There's nothing like a UNIQUE constraint in JCR or Jackrabbit (though
it might be good to have at least a Jackrabbit feature request in Jira
for that), so the closest you can get probably to make the "resource
name" be the name of the entry node and have all the entries stored as
children of a parent node that doesn't allow same-name-siblings.

  

OK that could work!

Alternatively you need to implement that constraint in your code.
Whenever creating a new node (or modifying the "resource name"
property) you could lock the subtree (or just a separate lock node)
and check that the constraint isn't being violated before saving the
changes.

I really don't want to lock the whole collection of entries though. That would mean I would get a LockException if another thread tried writing to that node, which 99.9999% of the time won't cause a conflict.

Cheers,
- Dan

[Jukka Zitting]

Hi,

On 11/5/07, Dan Diephouse <[hidden email]> wrote:
> Jukka Zitting wrote:
> > There's nothing like a UNIQUE constraint in JCR or Jackrabbit (though
> > it might be good to have at least a Jackrabbit feature request in Jira
> > for that), so the closest you can get probably to make the "resource
> > name" be the name of the entry node and have all the entries stored as
> > children of a parent node that doesn't allow same-name-siblings.
>
>  OK that could work!

There's an added benefit if you plan to use the "resource name" as a
primary identifier for the entries, as you'll then be able to use
normal path resolution instead of a more expensive query to retrieve
an entry.

BR,

Jukka Zitting

[Dan Diephouse]

Some javascript/style in this post has been disabled (why?)

Jukka Zitting wrote:

Hi,

On 11/5/07, Dan Diephouse [hidden email] wrote:
  

Jukka Zitting wrote:
    

There's nothing like a UNIQUE constraint in JCR or Jackrabbit (though
it might be good to have at least a Jackrabbit feature request in Jira
for that), so the closest you can get probably to make the "resource
name" be the name of the entry node and have all the entries stored as
children of a parent node that doesn't allow same-name-siblings.
      

 OK that could work!
    

There's an added benefit if you plan to use the "resource name" as a
primary identifier for the entries, as you'll then be able to use
normal path resolution instead of a more expensive query to retrieve
an entry.
  

Cool.

Another question though - which node type do I use to disallow same name siblings? I'm not quite keen on doing the File/Folder thing for some reason (maybe I should be?). I don't see any other node types that disallow same name siblings though. Does that mean I need to create my own node type? And if I create my own node type does that mean I have to do so via the Jackrabbit APIs? I don't see a way to do so via the JCR API.

- Dan

[Jukka Zitting]

Hi,

On 11/6/07, Dan Diephouse <[hidden email]> wrote:
> Jukka Zitting wrote:
> > There's an added benefit if you plan to use the "resource name" as a
> > primary identifier for the entries, as you'll then be able to use
> > normal path resolution instead of a more expensive query to retrieve
> > an entry.
>
>  Cool.

One caveat though, the names you use must then be valid JCR names, not
just any strings. As a workaround you can use some encoding if you
need to reliably use externally generated names as JCR names.

Also, note that Jackrabbit currently starts hitting performance issues
if you store too many (>> 1k) child nodes under a single parent. A
typical workaround to this issue is to split the child nodes into a
subtree based on the first few characters of the child node name.

> Another question though - which node type do I use to disallow same name
> siblings? I'm not quite keen on doing the File/Folder thing for some reason
> (maybe I should be?). I don't see any other node types that disallow same
> name siblings though. Does that mean I need to create my own node type?

I would probably use an nt:folder for the container node and a new
"atom:entry" subtype of nt:hierarchyNode for the entry nodes (or even
nt:file with custom jcr:content resource nodes). The more you leverage
the existing node types, the easier it will be to integrate with other
JCR tools (for example a file system mapping will definitely know what
to do with an nt:folder node).

Alternatively, for maximum flexibility, you can create your node types
from scratch. Either approach is valid.

> And if I create my own node type does that mean I have to do so via the
> Jackrabbit APIs? I don't see a way to do so via the JCR API.

JCR 1.0 didn't standardize node type management (it'll be standardized
in JCR 2.0), so currently you need to use a Jackrabbit-specific
extension to register new types. See the JackrabbitNodeTypeManager
extension interface in the jackrabbit-api package.

BR,

Jukka Zitting