Should the Item and Policy interfaces extend
Transactionable?
I have problems with some usecase I have created, which
involve manipulating
Users and Policies, if the usecase fails the repository
nodes are not
committed but the AC changes happen instantly.
I've done some playing around with this idea before but
reversed my changes
as it became a huge change to AccreditableManager,
ItemManager and
PolicyManager.
Basically I had to make sure the RepositorySession was
always passed all the
way down to PolicyManager.savePolicy (I know these don't
exist in the
interface, I'm implying FilePolicyManager or whatever other
implementation
it might be).
With the repository session present in
PolicyManager.savePolicy, the object
is not written but is marked to be written later when the
transaction is
committed, as with other repository objects. The
Transactionable.saveTransactionable implemented on the
Policy/Item will then
actually do the writing.
I also don't think that ac Items should be responsible for
creating and
saving themselves. Shouldn't their respective managers do
this for them?
Eg... UserManager should have a createUser method, this
makes it easier to
develop for different AC implementations as the Usecases no
longer need to
know which class to instantiate to create a user.
Likewise, the User object shouldn't save itself, the
UserManager should add
the Transactionable user object to the repository session so
it gets saved
when the transaction is committed.
Like to hear your thoughts...
Michael Ralston
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe lenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org
|