object committed in service layer - no call to dao?

[cblackbu]

Hello All,

I am a little confused as to why my objects are being saved from the service layer, without a call to my dao layer.

In a method in my service layer I receive my object that I am going to update by:

EntityGroup group = (EntityGroup) dao.getEntityGroup();

Then I make some changes to the group object.
At the end of the method, I make sure that the object is "safe" for saving. IE, the user did not remove things from the group that should be there, basically a validation. If the validation fails, I throw a custom Exception.

*Note: I found out about the transactionAttribue using something like

PROPAGATION_REQUIRED,-CustomException

which works great for rolling back the transaction, but lets say we don't use this*

However, even without this, I am not calling my dao.saveEntityGroup() method, so I would not think that the group object would be saved. Why is this object being flushed without a specific call to my dao layer?

I hope I explained this well enough.

Thanks in advance!

Chris

[Rod Johnson]

Sounds like you're using a persistence tool like Hibernate or a JDO implementation that supports automatic dirty checking. You don't need to tell it your objects are dirty and they need saving: it knows which objects are dirty and saves them automatically. Why don't you want this behaviour? Or do you just want to understand why it's happening?

[cblackbu]

Did I really write all that and not mention that I am using hibernate?
Sheesh..

So, yes exactly, I guess I wasn't aware that hibernate would do this. I would love to know why this is happening. Does this only happen if I change the object within the service layer (within a Spring transaction)? How/where do I configure this functionality?

Thanks again,

Chris

[Colin Sampaleanu]

Hibernate will track changes to any object that is obtained from and still attached to a live Session, and write it out when that Session is closed or the transaction is done.

This is basically the same way JDO would work too.

If you do not want the object saved, you are going to have to cause the transaction to roll back. As you figuredout, this means registering custom exception types, or relying on the default treatment of RuntimeException derived exceptions to cause rollback.

If you really want to use programmatic means to set the current tx to rollback-only, ala EJB, if you are using TransactionInterceptor (ie using the declarative transaction proxies, not TransactionTemplate), you can use:

TransactionInterceptor.currentTransactionStatus().setRollbackOnly()

while an approach that will work for both cases is:

 public static void setCurrentTransactionRollbackOnly(PlatformTransactionManager ptm) throws
TransactionException {
  TransactionDefinition definition = new DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_MANDATORY);
  TransactionStatus status = ptm.getTransaction(definition);
  ptm.rollback(status);
 }

where ptm is the PlatformTransactionManafer instance you are using, i.e. JTATransactionManager or HibernateTransactionManager.