I have bad news, Jeff.. :(
(Well, sort of.. there may be hope, see the end of the message).
The problem you're running into with jbpm 4 is that a database operation is being attempted with an object that, indeed, has a @LOB field -- which Postgresql handles with it's super cool (yay.. :/ ) "Large Object" facility[1].
See http://jdbc.postgresql.org/documentation/84/binary-data.html
The important sentence on that page is the following:
You must access Large Objects within an SQL transaction block. You can start a transaction block by calling setAutoCommit(false).
And somewhere deep in the jbpm 4 code, that's exactly what's not happening: jbpm 4 is creating, modifying or accessing an entity with a LOB field "outside" of a transaction. The code doesn't even have to modify the object/entity containing a LOB: even retrieving an entity with a LOB field will cause this problem.
The reason I happen to know about this is because I've been looking at this issue in jbpm 5 (with PostgreSQL, which is the only DB that has this)[2]. In jBPM 5, we're close to fixing the code so that it works. It's actually not that hard, I just have to be careful I don't break anything else while fixing it. ;) :/
Short of modifying the code in jBPM 4 yourself (it is open source!), I don't think there's a solution for this.
Wait, I take that back -- one of the possible solutions I looked into was modifying the mapping of the objects in question so that the LOB was stored as a byte array and not using the "Large Object" facility[1]. To tell the truth, though, I unfortunately just deleted the (git) stash and branch containing that stuff this week, after having not looked at it for a month. In short, I'm only about 85% sure that what I'm suggesting is possible -- and can't remember all the details of the solution.
[Oh yeah, now I remember -- the byte [] field in PostgreSQL is limited (wrt to size), and while the limit is pretty high, because of.. how jBPM 5 is put together, it wasn't the better solution. I don't think that jBPM 4 will have as large @Lob/byte [] fields, but I would check the maximum size of the byte [] fields in your Oracle jbpm 4 database. If the max size of the @Lob/byte [] field in the Oracle db is larger than the max allowable size of the byte [] field in PostgreSQL, then at least you have a good reason that upper management will understand when you tell them why you can't migrate the system. :) ]
I'm not at all unfamilar with jbpm 4, but the trick is the following:
- You need to have access (be able to modify) the persistence.xml in order to do this.
- If necessary, you can replace the persistence.xml in the appropriate jbpm 4 jar.
- You can override the mappings that are present in the classes:
- You will have to go through all the jbpm 4 code and find which entities these are.
- Then you will have write entity-mapping xml files for these entities.
- Make sure to include the xml-mapping-metadata-complete element in order to disable the anno's (including @Lob) in the java files.
- This make take some trial an error: I use eclipse's debugging capabilities with a good unit test for this type of thing.
- There are probably some other descriptions of how to do this, but see Pro JPA 2, pp. 373-375 for the overriding anno's and pp. 385-398 for some basic entity-mapping xml info.
- The order of elements is (bizarrely) important: make sure to verify your mapping (and the order of your xml elements) agains orm_1_0.xsd (or whichever schema you're using.)
- The mapping files you write for each entity must be referred to in your persistence.xml and if necessary, inserted in the appropriate jbpm 4 jar (see first bullet).
Good luck,
Marco
[1] The Large Object facility stores an id in the actual field of the entity, which then refers to a row/record in an another table where the actual byte data is stored -- hence the need for transactions since multiple tables are involved.
[2] Yes, the "Large Object" facility is unique -- unique like the way we made jokes about "special" people in middle school. ;D That said, there are actually worse databases out there with regards to (XA) transactions -- worse commercial databases, that make me Sy.. , I mean sigh. /:)