Concurrent implementations of abstract types usually rely on lock-free primitives or locks and are highly tuned to support a finite set of efficient operations. However, it is very hard to extend such types for specific needs by adding new operations. The synchronization based on memory transactions, which is generally less efficient than based on lock-free primitives or locks, has been proposed in part to address this issue by ensuring that any set of transactional operations can run concurrently. This paper introduces transaction polymorphism, a synchronization technique that consists of providing more control to the programmer than traditional (monomorphic) transactions to achieve comparable performance to generic lock-based and lock-free solutions. We show in this paper that, maybe unsurprisingly, monomorphic transactions cannot reach the level of concurrency obtained with locks. As a drawback of sharing the same semantics that needs to be strong enough for various operations, monomorphic transactions seriously underutilize the concurrency potential of such operations. We describe a Java polymorphic transactional memory that includes three distinct transaction types, which we compare against four existing (monomorphic) STMs, as well as against existing lock-based and lock-free synchronization on a collection micro-benchmark and on the STMBench7 macrobenchmark. Our results show that polymorphism can be at least 2.4 times faster than any of these alternatives on 64 threads.