More on database abstraction

Having complained about Rails not abstracting the database enough, I ran into the opposite problem at work.

One of the deployment platforms for our main system is JBoss1, and we use CMP entity beans for most of the persistence. I encountered a problem where a bean is created, and then later in the same transaction an ejbSelect is run that tries to join that bean with some other data. The problem is that JBoss hasn’t inserted the data yet, because it only guarantees to make it consistent on transaction boundaries.

I’ve worked around the problem by making the create in question non-transactional, so JBoss is forced to insert the data straight away, but this is not a very satisfactory solution because it could cause other problems. I need to do some more looking into how to control JBoss CNP.


I have a lesson to learn: maybe I should make a post about it. It turned out that the problem wasn’t what I thought it was. The data was being inserted correctly, but the second select was targetting a cached data source that we use for read-only data. i.e. one of the beans was configured to be read-only, when it appears from this operation that actually it wasn’t.

In the end we made a fix in a lateral way, by realising that the second select operation could be simplified – the new bean didn’t need to be joined to it. So we have a simplified query that really is using only read-only data.

1 The other platform is Weblogic, which doesn’t have this problem.

Post a Comment

Your email is never published nor shared. Required fields are marked *