Sorry to bump the post but I thought I should clarify my question :)
If I am within a user managed transaction's scope, and I have added a node
and then call session.save(), is it safe to rely on that node's UUID or
would I have to wait until the transaction has been committed?
Here is the excerpt from the JCR 1.0 specification:
4.9.1.1 When UUIDs are Assigned
In some client-server implementations the assignment of a permanent UUID
may be done on the server.
In these cases it is not practical for a newly created referenceable
node
to be given a UUID upon creation.
Rather, it makes more sense for the UUID to be assigned upon save of
that
node.
In such cases a “dummy UUID” may be assigned on creation of a new node
while the real UUID assignment takes place later, upon save.
Applications should not, therefore, rely on the UUID of a node before
that
node is saved for the first time.
Thanks again. Kind regards,
James
Gadbury wrote:
>
> Hi all,
>
> I have a number of Jcr-based Daos. In some cases, I have been using the
> session as a means to control a simple transaction. For example, I create
> a session and pass it to two different Dao create() methods. Only when
> all my Dao work is complete do I call session.save(). See my example code
> below:
>
>
> Session session = getSession();
>
> JcrUserDao userDao = new JcrUserDao();
> JcrProductDao productDao = new JcrProductDao();
>
> userDao.create(aUser, session);
>
> productDao.create(aProduct, session);
>
> session.save();
>
>
> The problem I have is that during a single transaction, I would like to
> create a multiple value property that contains strings for all node UUIDs
> created during the single transaction (i.e. hold 'weak' references to any
> newly created node UUIDs). I read in the specification that it is not
> safe to use a referenceable node's UUID until session.save() has been
> called and the changes have been persisted. However, with the above
> example, if I call save() before the two create methods have completed, I
> ruin my simple transaction.
>
> I have been reading the spec again regarding user managed transactions.
> Consider the following code:
>
>
> Session session = getSession();
>
> // Get user transaction (for example, through JNDI)
> UserTransaction utx = ...
>
> JcrUserDao userDao = new JcrUserDao();
> JcrProductDao productDao = new JcrProductDao();
>
> utx.begin();
>
> Node newUserNode = userDao.create(aUser, session);
>
> session.save();
>
> String UUID = newUserNode.getUUID();
>
> Node newProductNode = productDao.create(aProduct, session);
>
> session.save();
>
> utx.commit();
>
>
> After the first call to session.save(), would it then be safe to get a
> node's UUID?
>
> For example, in my JcrProductDao's create() method, I am creating one
> Product node and then create N number of ProductElement nodes by calling a
> JcrProductElementDao, again passing on the session. I would like a
> multiple value property of a Product to hold all new Element node UUIDs.
>
> However, I also read this in the JCR 1.0 spec:
>
> "Note, however, that changes made in the transient storage are not
> recorded by a transaction.
> This means that a rollback will not revert changes made to the transient
> storage of the Session.
> After a rollback the Session object state will still contain any pending
> changes that were present before the rollback."
>
> Does this mean that I shouldn't be using session and making transient
> changes with user managed transactions? I don't mind if I cannot revert a
> session's pending changes just as long as I can control when the changes
> are persisted and also reliably access a new node's UUID.
>
> Any help or advice would be greatly appreciated. Thanks for reading.
>
--
View this message in context:
http://www.nabble.com/User-Managed-Transactions...-tp24687924p24699832.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
