I need to save multiple object at once, and rollback all if one object fails to save.
For example :
class Transaction {
Item item;
}
class Item {
date lastTransaction;
}
If I create new Transaction, I need to change lastTransaction value and save the item.
If I failed to save the item, I need to rollback the Transaction (vice versa).
Any ideas?
Yuck. Don't throw exceptions to roll back transactions. You're incurring a pretty high cost to take advantage of a side effect where the transaction manager, assuming that a runtime exception means that you're not in control, automatically rolls back the transaction for you to keep you from doing more damage. It's a bit like being lonely and hitting yourself in the head repeatedly with a hammer so some EMTs and perhaps a nurse or a doctor will spend some time with you.
It's pretty easy to roll back a transaction, but unfortunately Grails doesn't expose any of this:
import org.springframework.transaction.interceptor.TransactionAspectSupport
class FooService {
def someMethod(...) {
boolean somethingBadHappened = ...
if (somethingBadHappened) {
// roll back
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()
}
// ok, proceed
...
}
}
And later you can check if the current transaction was rolled back with
TransactionAspectSupport.currentTransactionStatus().isRollbackOnly()
Note that this won't work in a controller since the transaction will have ended by that point.
Create a service method and put your persistence logic in there. When you call save, if you specify failOnError: true then if there are validation problems an exception will be thrown and your transaction will be rolled back.
def myServiceMethod(...some parameters...) {
....
Item item = new Item(lastTransaction: new Date())
item.save(failOnError: true)
Transaction transaction = new Transaction(item: item)
transaction.save(failOnError: true)
...
return transaction
}
Also, have a read through of the services section of the Grails docs.
Related
I'm using Grails 2.5.1, and I have a controller calling a service method which occasionally results in a StaleObjectStateException. The code in the service method has a try catch around the obj.save() call which just ignores the exception. However, whenever one of these conflicts occurs there's still an error printed in the log, and an error is returned to the client.
My GameController code:
def finish(String gameId) {
def model = [:]
Game game = gameService.findById(gameId)
// some other work
// this line is where the exception points to - NOT a line in GameService:
model.game = GameSummaryView.fromGame(gameService.scoreGame(game))
withFormat {
json {
render(model as JSON)
}
}
}
My GameService code:
Game scoreGame(Game game) {
game.rounds.each { Round round ->
// some other work
try {
scoreRound(round)
if (round.save()) {
updated = true
}
} catch (StaleObjectStateException ignore) {
// ignore and retry
}
}
}
The stack-trace says the exception generates from my GameController.finish method, it doesn't point to any code within my GameService.scoreGame method. This implies to me that Grails checks for staleness when a transaction is started, NOT when an object save/update is attempted?
I've come across this exception many times, and generally I fix it by not traversing the Object graph.
For example, in this case, I'd remove the game.rounds reference and replace it with:
def rounds = Round.findAllByGameId(game.id)
rounds.each {
// ....
}
But that would mean that staleness isn't checked when the transaction is created, and it isn't always practical and in my opinion kind of defeats the purpose of Grails lazy collections. If I wanted to manage all the associations myself I would.
I've read the documentation regarding Pessimistic and Optimistic Locking, but my code follows the examples there.
I'd like to understand more about how/when Grails (GORM) checks for staleness and where to handle it?
You don't show or discuss any transaction configuration, but that's probably what's causing the confusion. Based on what you're seeing, I'm guessing that you have #Transactional annotations in your controller. I say that because if that's the case, a transaction starts there, and (assuming your service is transactional) the service method joins the current transaction.
In the service you call save() but you don't flush the session. That's better for performance, especially if there were another part of the workflow where you make other changes - you wouldn't want to push two or more sets of updates to each object when you can push all the changes at once. Since you don't flush, and since the transaction doesn't commit at the end of the method as it would if the controller hadn't started the transaction, the updates are only pushed when the controller method finishes and the transaction commits.
You'd be better off moving all of your transactional (and business) logic to the service and remove every trace of transactions from your controllers. Avoid "fixing" this by eagerly flushing unless you're willing to take the performance hit.
As for the staleness check - it's fairly simple. When Hibernate generates the SQL to make the changes, it's of the form UPDATE tablename SET col1=?, col2=?, ..., colN=? where id=? and version=?. The id will obviously match, but if the version has incremented, then the version part of the where clause won't match and the JDBC update count will be 0, not 1, and this is interpreted to mean that someone else made a change between your reading and updating the data.
I have the following
def save(ACommand command){
...
}
#Validateable
class ACommand implements Serializable
{
ADomainObject bundleDef
}
but every time save is called the version is incremented. So if I open up two browsers and submit a different value in succession, instead of getting an error the second time as I would expect, the value is updated.
I also tried using two different sessions with no difference
Update
If I use breakpoints and submit before the other one is completed it works fine. However, If I let the first complete then submit the second without a refresh the version is updated to the newer one (which I don't want) and the change goes through.
Update 2
When you perform updates Hibernate will automatically check the version property against the version column in the database and if they differ will throw a StaleObjectException. This will roll back the transaction if one is active.
per Grails this should work seems to me.
AFAIK, you need to check the version and handle failures yourself - it doesn't happen automatically. You can do this with code like this:
/**
* Returns a boolean indicating whether the object is stale
*/
protected boolean isStale(persistedObj, versionParam = params.version) {
if (versionParam) {
def version = versionParam.toLong()
if (persistedObj.version > version) {
return true
}
} else {
log.warn "No version param found for ${persistedObj.getClass()}"
}
false
}
you can call isStale from an action like this
def update() {
Competition competition = Competition.get(params.id)
if (isStale(competition)) {
// handle stale object
return
}
// object is not stale, so update it
}
I am not sure what you expect to happen but what you describe sounds correct to me unless you have code in your save() action that is relevant.
You can't expect Hibernate to do anything special here. When your save() action is invoked the instance is retrieved using Hibernate, mutated and then saved. That is all fine as far as Hibernate is concerned.
One way to deal with this is when the form for editing the entity is rendered, render the version of the entity that is being edited to a hidden form field which will be submitted when the entity is saved. In the save action after retrieving the entity from the database compare its version to the version retrieved from the hidden form field and if they don't match you know that the entity was modified between those 2 steps and you can react however is appropriate for your app. Note that since your example is using a command object, data binding is being imposed on the entity before your code ever executes. If that isn't what you want, don't use a command object.
I hope that helps.
If I have two flushes on the same thread using GORM, is it possible for the first to pass and the second to fail in separate transactions?
Or even if I just have one flush half way thru the thread and then a second implicit flush after the request finishes, is it is possible for the second to fail but the changes from the explicit flush to pass and thus be persisted in the DB?
Thanks
If I have two flushes on the same thread using GORM, is it possible for the first to pass and the second to fail in separate transactions?
It's the transactions that succeed/fail, not the flushes. There's an implicit flush at the end of every transaction, and also at the end of every session (request). It's absolutely possible to have several transactions in the same thread, some of which fail, and some of which succeed. For example, given a simple domain class
class Book {
String title
}
The first transaction in someAction will succeed and the second will be rolled back.
class MyController {
def someAction() {
Book.withTransaction {
new Book().save(title: 'successful').save(failOnError: true)
}
Book.withTransaction {
new Book().save(title: 'failed').save(failOnError: true)
throw new RuntimeException('transaction rollback')
}
}
}
I have Machine and Parts domain class
In my service class I am trying to start a transaction, inside that transaction i want to create a new transaction and commit it when it comes out of the inner transaction.
Machine.withTransaction { // transaction 1
// some code to add Parts
// some code to remove Parts
Machine.withNewTrasaction { // transaction 2
// some code to remove Parts.
} // end of transaction 2
// some code to update couple of columns in machine table.
}// end of transaction 1
When it comes out of transaction 2 I want transaction 2 be commited the Parts for the Machine irrespective to transaction 1.But grails is throwing an error back as "Illegal attempt to associate a collection with two open sessions"
How to commit the transaction 2 alone separately without considering the transaction 1?
You can try handling transaction explicitly using #Transactional annotation inside the service class.
Notes:-
Once you add #Transactional annotation to service method, the service class is not deemed transactional by default.
Since you splitting the functionality into two methods, you have to use the proxied instance of the service class to call the second method otherwise you cannot create a new transaction for the second method. Hence, use of applicationContext below in method 1.
You would not need withTransaction or withNewTransaction block any more.
Service class would look like:
class MachineService{
#Transactional
def someMethodToAddParts(){
......
grailsApplication.mainContext.machineService.someMethodToRemoveParts()
......
}
#Transactional(propagation = TransactionDefinition.PROPAGATION_REQUIRES_NEW)
def someMethodToRemoveParts(){
.......
}
}
I've encountered a slightly different problem, maybe it can help somebody, and maybe it could help for the above problem.
I think that the above problem could be avoided by merging entities to the new transaction, then use .merge() method on the collection causing the problem.
First I think the above code looks like this (I've added comments to explain) :
Machine.withTransaction { // transaction 1
// some code to add Parts
yourEntity.addToParts(...)
// some code to remove Parts
Machine.withNewTrasaction { // transaction 2
// some code to remove Parts.
yourEntity.removeFromParts(...)
} // end of transaction 2 -> the session is flushed, and the transaction is committed
// during the flush, hibernate detect that "parts" collection is already attached
// to another session, in another transaction then throw "Illegal
// attempt to associate a collection with two open sessions"
// some code to update couple of columns in machine table.
}
Then the solution is to merge the collection to the new transaction, it give us something like this :
Machine.withTransaction { // transaction 1
// some code to add Parts
yourEntity.addToParts(...)
// some code to remove Parts
Machine.withNewTrasaction { // transaction 2
// some code to remove Parts.
yourEntity.removeFromParts(...)
// Merging the collection to the session
yourEntity.merge() // I haven't tried but maybe you need ensure
// there is a merge cascade on "parts" collection
} // end of transaction 2 -> the session is flushed, and the transaction is committed
// some code to update couple of columns in machine table.
}
In my case, with a merge in the new transaction, I solved the error message "A different object with the same identifier value was already associated with the session : [yourPackage.YourEntity]" (when I talk about YourEntity, you can also read YourDomaineClass)
My users are uploading a csv or xls or whatever and each line is going to be an instance of a domain object I save. If any of the lines fail I want the whole thing rolled back, but I also want to return errors for any lines that will fail later. Let's make an example:
Domain class:
MyDomainClass{
String fieldOne
BigDecimal fieldTwo
}
Input:
ThisLineWorks,4.4
ThisLineFails,BecauseOfThis
How would I also get an error, for this line as well considering the last one would have rolled back the transaction already?
Fantasy Output:
OK|ThisLineWorks,4.4
field 2 isn't a number|ThisLineFails,BecauseOfThis
field 2 isn't a number|How would I also get an error, for this line as well considering the last one would have rolled back the transaction already?
You can validate the objects without having to save them: ( http://grails.org/doc/2.0.x/guide/validation.html#validatingConstraints). So in a service you can create all of the objects, then validate all of the objects, then save all of the objects. Something similar to:
def serviceMethod(data) {
def listOfObjects = createObjectsFromData(data)
listOfObjects*.validate()
def anErrorOccurred = listOfObjects.find {it.hasErrors()} != null
if(anErrorOccurred) {
return listOfObjects
}
listOfObjects*.save(validate: false) //you could use the validate:false or leave it out. I figure since we've already validated that you could do without re-validating.
}
This way you can collect all of your errors and not have to worry about rolling back the transaction. Problem with this setup is you'll be creating N number of objects and holding onto all of them. If your file is longer than 100k rows (a slightly educated guess on where you'll start to suffer) then this might cause some performance issues. If you don't like the above method you could handle the transaction manually:
( http://grails.org/doc/2.0.x/ref/Domain%20Classes/withTransaction.html)
def serviceMethod(data) {
MyDomainClass.withTransaction { status ->
def listOfObjects = []
data.each {
def domainObject = createObjectFromData(it)
lisOfObjects << domainObject.save()
}
def anErrorOccurred = lisOfObjects.find {it.hasErrors()} != null
if(anErrorOccurred) {
status.setRollbackOnly() //will roll back all of the transactions surrounded by the .withTransaction {}
}
}
}
You're still holding onto all of the objects here (since you want to retrieve ALL errors that occur). One way I can think of to avoid holding onto all of the objects would be to create the objects one at a time and validate them one by one adding errors to a list when applicable, but then you'd have to recreate all of the objects when they all pass validation which doesn't seem very efficient either.
here is what i am thinking:
1 . Set a flag that signals ALL CLEAR and commit the transaction manually at the end if all is clear.
or
2 . Commit each line in a separate transaction capturing errors of failed lines and skipping over failures.