This is the last part in the series of “Making sense of EJB3.x Transaction Attributes“. So far, we’ve discussed transaction attribute type REQUIRES_NEW, MANDATORY, SUPPORTSand NOT_SUPPORTED. Here, we’ll cover the last attribute which is “NEVER“. The NEVER transaction attribute type is a simple one, but yet sometimes, it is difficult and confusing to where it can be applied in your Java EE project. This is a very short article with no code samples except to tell you where I think the NEVER transaction attribute type should be used.
(more…)
Oracle had extensively documented the behavior of each transaction attributes in the Java EE documentation, but they always fail to provide an extensive coverage on when and where these individual transaction attributes are supposed to be used and in what context of business logic are these democrats deem suitable.
(more…)
In my previous post, we’ve discussed about TransactionAttributeType.REQUIRES_NEW: how it behaves and where is a good spot to use it. In this post, which is the 2nd part of the series, we’ll explore TransactionAttributeType.MANDATORY.
(more…)
For the previous past posts, I have dealth much with manual fine-grind transaction, mostly on the subject of Bean-Managed Transaction with javax.ejb.UserTransaction and I’ve talked about what were the differences between rollback() and setRollbackOnly(). Don’t be surprise that Container-Managed Transaction could achieve similar control over transaction if transaction demarcates are properly used. I am writting a series of linked-articles to address usage of @TransactionAttribute with TransactionAttributeType such as REQUIRES_NEW, MANDATORY, SUPPORTS, NOT_SUPPORTED and NEVER.
(more…)
After JTA was introduced for more than a decade ago, then later with the introduction of Bean-Managed Transaction and Container-Managed Transaction in the J2EE 1.2 specs; still, there are many developers, especially those whom had just gotten their feets wet in the marvelous world of Java EE programming were confused when to and not to use the rollback() and the setRollbackOnly() method in the UserTransaction or the EJBContext class. Perhaps you may be coding fine grind transactional methods and have no idea why expections are all over the place and the rollback() or setRollbackOnly() just doesn’t seem to perform according to your expectation. You might think that both methods are the same (but its not). Is this the reason why you have landed on this page through google or through other web sources trying to shade some light?
(more…)
Let’s face it, different Databases have different ways of generating primary key values, either in the form of identity or through a sequence generator, if the primary key field is of a numerical data type. While coding Entity classes, it is necessary to define whether the primary key value (if is it of numerical type) could be generated from the sequence generator, self generated and inserted in the database during persistent or just self define. There are also times whereby your application would rather depend on a custom created table in the DB just to store generated sequential numbers as primary keys for the Entity. So, in this article, we’ll explore 3 ways in dealing with generating primary key values with the databases that support it and how to use the @GeneratedValue annotation effectively.
(more…)
In this article, we will explore how to store any simple file in database through EJB3 JPA and how to code the property field and the proper annotation type in the entity class.
(more…)
Glassfish is one app server where by accessing Local Stateless Session Bean is a somewhat “confusing” as compared to other App Servers. This post will show you 3 quick, easy, straight forward, no fussed and no debates different ways that you could access your Local Session Beans to get the job done. Yes, only Local Session Beans, NOT Remote Session Beans.
(more…)
A Many-To-Many relationship is where by multiple object(s) are related other multiple object(s) and vice-versa. The simplest way to illustrate this is through a directory system where user(s) are related to one or many other group(s) and each group consists of multiple user(s) which belongs to.
(more…)