aspose file tools*
The moose likes Performance and the fly likes Is Transaction management necessary for a release? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Is Transaction management necessary for a release?" Watch "Is Transaction management necessary for a release?" New topic
Author

Is Transaction management necessary for a release?

Jennifer Zhen
Greenhorn

Joined: May 24, 2009
Posts: 28
We are having a system without very good transaction management. It is automatically implemented on the service layer by Spring, but these service calls were not in the right granularity so that multiple calls often happen. Without a higher level transaction management, is it possible to cut the release to production?

This is not a financial application. Most of the developing members agree on having one, however, the manager was afraid of any code change (obviously he doesn't understand code either), and the BA was saying this is just a nice to have, "the system is working, why transaction management?" But most developers feel this is a basic to have. Do you also agree?

I have to admit in this very application, if some data integrity was damaged in a small scale, it probably could get back through manually running some reports on abnormal cases. But when the system is in stress, some other unclear risks may exist, which make me believe tx is still a must to have, can you help me identify the other risks?

thanks,

appreciate hints and tips
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Without knowing your business requirements its hard to say for sure. If you can ask your business "is it OK that sometimes the application loses data, or saves data that is invalid" and they say yes, then you don't need transactions. I'd be a little surprised if this were acceptable though.

Typically, multi user systems that have a small load (which is normal while developers are working on it) you can get away with quite a lot. But if you load the system lots more more errors tend to creep in, so using the application without stress testing its behaviour as a guide is probably not representative.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Jennifer Zhen
Greenhorn

Joined: May 24, 2009
Posts: 28
Paul Sturrock wrote:Without knowing your business requirements its hard to say for sure. If you can ask your business "is it OK that sometimes the application loses data, or saves data that is invalid" and they say yes, then you don't need transactions. I'd be a little surprised if this were acceptable though.


I am not sure if business knows and if they are willing to tell them about the accuracy risk as well.


Paul Sturrock wrote:Typically, multi user systems that have a small load (which is normal while developers are working on it) you can get away with quite a lot. But if you load the system lots more more errors tend to creep in, so using the application without stress testing its behaviour as a guide is probably not representative.


We did a "stress test", and ended up with a lot of failed sessions. Then we fixed the connection pool configuration, everything seems going fine now. So would that indicate we have addressed all the issues the system might have under production load?

btw, we are anticipating 200 concurrent users.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11419
    
  16

Jennifer Zhen wrote:We did a "stress test", and ended up with a lot of failed sessions. Then we fixed the connection pool configuration, everything seems going fine now. So would that indicate we have addressed all the issues the system might have under production load?

I would say that without a doubt, you have NOT addressed ALL the issues. I think it is next to impossible to cover all situations, regardless of how much testing you do. It would be naive to think otherwise.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Jennifer Zhen
Greenhorn

Joined: May 24, 2009
Posts: 28
fred rosenberger wrote:
I would say that without a doubt, you have NOT addressed ALL the issues. I think it is next to impossible to cover all situations, regardless of how much testing you do. It would be naive to think otherwise.


So is it right that the worst case would be some people experience thrown exceptions, and cause some bad data, and then the mess might stop due to our intervention. And the bad data would (if they knew it, as I said, they probably are not even aware of the situation) be manually fixed.

Is this a valid imagination?
you just don't know what to do with those people..

 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Is Transaction management necessary for a release?