instance not of expected entity type: org.jbpm.graph.def.Act

[ralfoeldi]

Hi all,

today I have an somewhat desperate cry for help: 'HELP!' :-)

I am getting a HibernateException 'instance not of expected entity type: org.jbpm.graph.def.Action' in LoggingSession.findLogsByToken(long tokenId)

The token and processInstance I am trying to retrieve logs for are ended and persisted so they should conform to all mappings etc.

I'm desperate because I just noticed this and part of the application is already on it's way down the deployment path (not a trivial thing if the three letter company is doing the deployment.)

So anybody who has a hint NOW as to whats happening would be very much appreciated :-)

Greetings

Rainer

[ralfoeldi]

I've isolated the problem.

Just creating the Query

select pl from org.jbpm.logging.log.ProcessLog as pl where pl.token = :token order by pl.index

(this is from LoggingsSession.findLogsByToken() ) already throws a HibernateException: instance not of expected entity type: org.jbpm.graph.def.Action. So data isn't the problem. I don't even get that far.

Still gratefull for any hints.

Rainer

[ralfoeldi]

This one was bizarr!

Hibernate does an autoflush when createQuery is called (I don't know if this always happens but in this case it did and to find out I had to trace 15 stacklevels of Hibernate code)

As I have some 'transient' objects in the current processInstance (I remove them before persisting, see Thread on RuntimeActions) this caused the excpetion. Setting session.setFlushMode( Commit ) did the trick.

Rainer

[koen.aers]

Rainer,

You are truely a champion in solving your own problems! Anyway it is great that you keep us posted on your struggles.

Thanks a lot and regards,
Koen

[tom.baeyens]

by default hibernate will flush before it executes a query. that is normal cause the modified data related to your session could be involved in the query. and the query is executed in the db. that's why hibernate has to flush at query time.

anyways. some very impressive digging !

is there anything we could do in the jbpm code to handle this situation ?

regards, tom.

[ralfoeldi]

Hi guys,

sorry for the panic, but I was working against the clock and willing to take any humiliation connected with stupid questions :-) Speed was all that mattered.

What surprised me was that it was tested code that threw up this problem. I was just playing around with some very rare scenarios in the lull before final deployment and all of a sudden it goes doom! I haven't yet figured out what caused the change (and it wasn't realy a priority.)

No there is nothing you should(!) do in jBPM code as the flushing is correct behaviour if you take 2 minutes to think about it, but thanks for asking. The root cause of the problem was my 'magic' adding transient runtime actions to the processInstance on the fly. I remove all instances + the corresponding logs before saving the processInstance, but that wasn't enough or rather soon enough in this case.

You missed out on a case of beer though. That would have been the next level of coaxing :-)

Greetings

Rainer

[koen.aers]

"Rainer" wrote:
sorry for the panic, but I was working against the clock and willing to take any humiliation connected with stupid questions :-)

I would say you deserve bonus points instead of humiliation ;-)

Cheers,
Koen

[koen.aers]

"Rainer" wrote:
You missed out on a case of beer though.

This is a pity though... Our thirst is legendary ;-)