• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Stateless Session Bean without transactions

 
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ranchers,

is it recommended to annotate every SLSB-method that does not use entities or TXs with

@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)

Would this annotation increase the performance of the method call?

Kind regards
Oliver

 
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy Olivier!

Take a look at this article by Adam Bien: http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos

There is always an overhead, but it's quite small. I would say that annotating EJB's as transaction's NOT_SUPPORTED is more important for the readability and maintenance of the code than the performance.

Hope that helps!

Cheers!
 
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What Pedro said is true,

But there are some cases where it could lead to performance bottle neck, like distributed transaction and remote objects. I've heard once that great companies like Google does not use distributed transaction because of this, that they use transactions just at low-level granularity (to ensure small chunks to be executed together).

I really don't know and haven't read or experienced such kind of issue, but it makes sense because nowadays we want to abstract our infrastructure and balance the load among several nodes. Imagine a horizontally distributed environment with distributed transaction two-phase commit. Or worst, imagine the transaction manager having to synchronize everything and having to ensure ACID in a distributed environment.

This kind of issues and questions lead to solutions like cloud computing, grid computing, BASE transactions, NoSQL, CAP theorem, etc. That's a nice topic that I want to go deeper!
 
Piotr Nowicki
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for adding this info Jayr!
I referred to rather simple applications but as you said - 2PC can be a real killer.

Jayr wrote:That's a nice topic that I want to go deeper!



We must go deeeeeper Leo
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Pedro & Jayr, many thanks for the quick answers and the clarification.

The article by Adam Bien is very interesting!
 
reply
    Bookmark Topic Watch Topic
  • New Topic