I am trying to do some bench-marking of Distributed transaction memory using Terracotta Ehcache (Open Source). I am having some problem understanding its working with JTA. In code I have found that cache interested in a Distributed Transaction enlist itself as a resource with JTA on which JTA later executes the two phase commit.
My question is if only one cache is enlisted as a resource, how JTA will be able to update all other caches atomically in distributed settings? We are not passing other caches reference to JTA, so atomically update will not be done on them. I feel, I am missing some string here, can anyone explain how it works? I am new to J2EE too, am I missing some J2EE concept which allow automatic reference passing of other caches to JTA?
Ehcache, if configured that way (transactionalMode="xa" or transactionalMode="xa_strict"), can work as a full XAResource to participate in JTA transactions (global transactions), which is controlled by a Transaction Manager (from your application server or some standalone product). Ehcache itself takes care of registering at the Transaction Manager in this case. Also, as a full XAResource, multiple caches can be registered and can be part of a transaction.
Strong, cluster-wide consistency is quite expensive (there is no free lunch). It boils down using locks and synchronous (network) operations involving waits, acknowledging etc.
For a more detailed read, I'd suggest you to consult Ehcache docs: Transactions in Ehcache
Each cache configured with transactionalMode="xa_strict" and updated within a JTA transaction will register itself as an XAResource to the transaction manager. This is all automated and transparent to the end user, you don't have anything special at all to do for this mechanism to kick in, you just have to use your cache inside a JTA beg
If you also happen to access other, non-transactional caches in the JTA transaction context, those won't be part of the transaction and will simply be updated as soon as you modify them.
Tried xa_strict but there seems to be no automatic enlistment of the XAResource? Switching to plain xa works though...
Related
I need to implement Ehcache in a project that uses Spring version 3.1 and Websphere. I tried to google something about this topic but I could'nt find anything. Have you guys ever used those three tools together? Thanks in advance.
As per EhCache docs,It will NOT detect Websphere Transaction Manager automatically,.
Automatically Detected Transaction Managers
Ehcache automatically detects and uses the following transaction
managers in the following order:
GenericJNDI (e.g. Glassfish, JBoss, JTOM and any others that register
themselves in JNDI at the standard location of
java:/TransactionManager
Weblogic (since 2.4.0)
Bitronix
Atomikos
No configuration is required; they work out of the box. The first found
is used.
And you can configure it as below.
If your Transaction Manager is not in the above list or you wish to
change the priority, provide your own lookup class based on an
implementation of net.sf.ehcache.transaction.manager.TransactionManagerLookup and
specify it in place of the DefaultTransactionManagerLookup in
ehcache.xml:
<transactionManagerLookup
class= "com.mycompany.transaction.manager.MyTransactionManagerLookupClass"
properties="" propertySeparator=":"/>
And to integrate & Use Spring with EhCache, refer this link
From Spring docs,
36.3 Declarative annotation-based caching For caching declaration, the abstraction provides a set of Java annotations:
#Cacheable triggers cache population #CacheEvict triggers cache eviction
#CachePut updates the cache without interfering with the method execution
#Caching regroups multiple cache operations to be applied on a
method
#CacheConfig shares some common cache-related settings at class-level
I'm looking at performance issues with a Grails application, and the suggestion is to remove the transactions from the services.
Is there a way that I can measure the change in the service?
Is there a place that has data on how expensive transactions are? [Time and resource-wise]
If someone told you that removing transactions from your services was a good way to help performance, you should not listen to any future advice from that person. You should look at the time spent in transactions and determine what the real overhead is, and find methods and entire services that are run in transactions but don't need to be and fix those to be nontransactional. But removing all transactions would be irresponsible.
You would be intentionally adding sporadic errors in method return values and making your data inconsistent, and this will get worse when you have a lot of traffic. A somewhat faster but buggy app or web site is not going to be popular, and if this doesn't help performance (or not much) then you still have to do the real work of finding the bottlenecks, missing indexes, and other things that are genuinely causing problems.
I would remove all #Transactional annotations and database writes from all controllers though; not for performance reasons, but to keep the application tiers sensible and not polluted with unrelated code and logic.
If you find one or more service methods that don't require transactions, switch to annotating each transactional method as needed but omit the annotation at class scope so un-annotated methods inherit nothing and aren't transactional. You could also move those methods to non-transactional services.
Note that services are only non-transactional if there are no #Transactional annotations and there is a transactional property disabling the feature:
static transactional = false
If you don't have that property and have no annotations, it will look like it's ok, but transactional defaults to true if not specified.
There's also something else that can help a lot (and already does). The dataSource bean is actually a proxy of a proxy - one proxy returns the connection from the pool that's a being used by an open Hibernate session or transaction so you can see uncommitted data and do your queries and updates in the same connection. The other is more related to your question: org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy which has been in Spring for years but only used in Grails since 2.3. It helps with methods that start or participate in a transaction but do no database work. For the case of a single method call that unnecessarily starts and commits an 'empty' transaction, the overhead involved includes getting the pooled connection, then calling set autocommit false, setting the transaction isolation level, etc. All of these are small costs but they add up. The class works by giving you a proxied connection that caches these method calls, and only gets a real connection and invokes these method on it when a query is actually run. If there are no queries and the only calls are those transaction-related setup methods, there's basically no cost at all. You shouldn't rely on this and should be intentional with the use of #Transactional annotations, but if you miss one this pool proxy will help avoid unnecessary work.
I have a spring application which is based on Spring Batch. By default spring batch introduces transaction for its steps (i.e. at reader,writer and processor) . There are certain stages where I don't really need transaction to be enabled. Because transaction is enabled unnecessary for these methods its giving me some runtime errors as I am making call to two different databases in one method.
Is there any annotation which spring provides to DISABLE transaction for a specific set of methods ?
OR is there anything available in spring batch which can allow me to get rid of transaction either completely or declarative
I am even open to the solution which can disable transaction globally.
Any link , paper will greatly be appreciated.
Thanks in advance
Samir
Spring Batch is inherently transactional. Even if your datasources are not transactional, the semantics of the JobRepository require it. The closest you can get with Spring Batch and not being transactional is using the ResourcelessTransactionManager. This transaction manager is essentially a no-op transaction manager that just keeps track of if an operation is within the scope of a transaction or not.
Im working with the Spring Framework 3.0.5 and the Hibernate Framework and Im starting to use now Springs Transactionmanagement. I have some questions, just to understand how Springs Transactionmanagement works.
1)
I read this things in the Spring reference:
a) Consistent programming model across different transaction APIs such as Java Transaction API (JTA), JDBC, Hibernate, Java Persistence API (JPA), and Java Data Objects (JDO).
b) Spring resolves the disadvantages of global and local transactions. It enables application developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management strategies in different environments.
c) Gone are the days when the only alternative to using EJB CMT or JTA was to write code with local transactions such as those on JDBC connections, and face a hefty rework if you need that code to run within global, container-managed transactions. With the Spring Framework, only some of the bean definitions in your configuration file, rather than your code, need to change.
From a) I understand that I can use those APIs with Spring without changing the code
From b) I understand that I can use global or local transactions *without changing the code
From c) I understand that while switching between different APIs and global/local transactions I need to change the code
Now I wonder what is correct?
=> Do I need to change the code? When switching between different APIs? When switching between local and global transactions? (Or does it maybe depend on prorgammatic and declarative transaction management?)
2)
I also got an additional question: I really wonder what the use of programmatic transaction management is? Everywhere I read that declarative transactionmanagement is recommended
I read this in spring reference too:
d) With programmatic transaction management, developers work with the Spring Framework transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code related to transaction management, and hence do not depend on the Spring Framework transaction API, or any other transaction API.
From d) I understand: with programmatic transaction management I can use any underlying transaction infrastructure... which means what? the different APIs mentioned above?
and: with declarative I do not depend on any api
=> isnt this the same? when I can use any underlying api, I do not depend on any api. I do not really understand this.
where is the difference? I only know that the declarative transaction management is more lightweight, that I have not to start the transaction by my self and catch the exception and handle it and so on. But what is the use of programmatic transaction management then?
Thank you for answering! :-)
You're over-thinking this a bit. The Spring API provides an abstract transaction model that has the same API and semantics regardless of which underlying transaction technology you use. In order to switch from one technology to another, you generally have to alter your Spring config, but the idea is that you never needs to to alter your business logic. So whether you're using local, in-VM JDBC transactions or fully distributed, two-phase-commit XA JPA-style transactions, the API usage within your Spring code is the same. Only the configuration changes.
The difference between declarative and programmatic transaction management is that with the former, you use annotations or XML config to say which bits of code are supposed to be transactional. With programmatic style, you specifically enclose transactional logic using method calls into the Spring API. Note that if you use the declarative style, then Spring will wrap your code in generated logic which uses the programmatic style. The latter is simply a more explicit and low-level version of the former. It gives you more control, but it's more verbose.
my confusion related to this matter is that how we can use a previously created transaction? or in other words how many threads a transaction could be related to?
A transaction can be related to only one thread in spring. Well, with some effort you can make it a long-running transaction, but that's an anti-pattern afaik.
REQUIRES_NEW means that whenever the program flow enters the annotated method, a new transaction will be started regardless of any existing transaction.
REQUIRED means that an existing transaction will be reused, or if there's no existing transaction a new one will be started.