Seam-Persistence & Glassfish - sometime cannot write to database

[baraber]

Hello guys, this one caused me a lot of headache

I use Glassfish 3.1(b-43) with seam-persistence (3.0.0.Final).  Replaced weld osgi bundle in glassfish to version 1.1.1.Final. 

Sometimes the application cannot issue insert statements in the database.  By this I mean I activated the query logs and I see all read queries but not write queries.  But the problem is inconstant.  Some time when I start the application all works fine.  Some other times write queries aren't processed. 

When the problem happens, I just restart the application and have a chance it will work.  If not, restart again, and again...  When it works, it seems to keep working until I restart.

I can have no problem at all across multiple restarts as I may have to restart it multiple time before all works fine.

I first noted the problem on a personal application.  Being unable to find any information on a similar problem, I had to remove seam-persistence from my project to use an ejb with @PersistenceContext and the problem seemed to be gone completely.

But not I have to use seam-security, who itself uses seam-persistence.  And again I face the problem. 

One can test it with the seam-security idmconsole example.
To test, juste start idmconsole in glassfish, log in(demo/demo), and try to create a new user.  Sometime all is ok, but other times, I cannot create the user :

Caused by: javax.persistence.NoResultException: getSingleResult() did not retrieve any entities.
...
at org.jboss.seam.security.management.picketlink.JpaIdentityStore.lookupIdentity(JpaIdentityStore.java:1233)
at org.jboss.seam.security.management.picketlink.JpaIdentityStore.updateCredential(JpaIdentityStore.java:1803)
at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.updateCredential(WrapperIdentityStoreRepository.java:310)
at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.updatePassword(AttributesManagerImpl.java:563)
at org.jboss.seam.security.management.action.UserAction.saveNewUser(UserAction.java:156)
at org.jboss.seam.security.management.action.UserAction.save(UserAction.java:133)
...

The following line throw the exception
(org.jboss.seam.security.management.picketlink.JpaIdentityStore.lookupIdentity(JpaIdentityStore.java:1233))):

return em.createQuery(criteria).getSingleResult();

This is because of org.jboss.seam.security.management.action.UserAction.saveNewUser(UserAction.java:155, 156) :

User user = identitySession.getPersistenceManager().createUser(username);
identitySession.getAttributesManager().updatePassword(user, password);

The call to createUser should have inserted in database so that the call to updatePassword could look the user up and then update its password. 

I tried it with hibernate and eclipseLink : same problem. 
Tried with XADatasource and non XA datasource : same problem. 
Tried with java db(come with glassfish) and with MySQL : same problem.

Can someone help with this, or had similar issue ?  Or is anyone using seam-persistence with glassfish without any trouble ?

We never stumble across this problem with JBOSS as.

[mimik789]

I found that db write issues with seam-persistence module may be related to it's transaction interceptor (CDI interceptor) that somtimes isn't registered (probably because of classloading/cdi glassfish issues). A solution for that (which works in our project) is to copy sources of seam-persistence transaction interceptor (and associated classes) to webapp src (to be compiled in WEB-INF/classes = war). I added some logging to seam-persistence code and found that sometimes transaction interceptor from seam-persistence.jar is picked up, and other times it's missed and - then these copied to webapp is comming to rescue - and indeed it'll be registered for jar's missed. I can provide more details if needed (files list/modifications) - when I'll be at my office where I have access to our webapp sources.

[baraber]

Oh, that really make sense.

But, I did not manage to make it work yet. 

What I've done is to copy the transaction interceptor in seam security idmconsole source code, recompiled and tested.  I had the error the 8th time I restarted the application.

Note that the interceptor is configured in seam-security-impl jar file in META-INF/beans.xml, and therefore not in idmconsole WEB-INF/beans.xml.  Being not sure if that could be part of the issue, I removed the configuration in seam-security-impl to place it in idmconsole, but that didn't do the trick.

You mentionned that you did copy the interceptor AND and associated classes...
Did you try to copy only the interceptor to see if it work ?

If you could provide the exact list you copied maybe it would be helpful.

[mimik789]

Regarding beans.xml and registering of the interceptor - yes it's needed but I placed it under WEB-INF/beans.xml (not META-INF), and there should be:
   <!-- enable declarative transaction management for managed beans -->
   <interceptors>
      <class>org.jboss.seam.persistence.transaction.TransactionInterceptor</class>
   </interceptors>

seam-persistence classes list (and these "associated"):
TransactionalInterceptorBinding
TransactionInterceptor
TransactionInterceptorBindingLiteral
(place them under original package name)

PS
our seam powered webapp use CR1 release of Seam3 (but I'm going to upgrade it to Final soon)

if you are curious what is happening under the hood, you may add logging statements to
TransactionInterceptor

(best if added both in jar (seam-persistence.jar) and in that class copied to webapp)
//add logger at begining of class body (slf4j)
private static final Logger log = LoggerFactory.getLogger(TransactionInterceptor.class);
//add this as first line in aroundInvoke method
log.trace("seam-persistence-impl(jar) interceptor fired: TransactionInterceptor:aroundInvoke for transactional method: {}", invocation.getMethod() );

//configure logger properly

that logs should appear before saving to db

[baraber]

hum, I tried what you said and many other ideas but the interceptor is not always enabled.  (still intermittent).

I uploaded my war there : https://s3.amazonaws.com/baraber/security-idmconsole.war

Can you take a look and tell me if there is something obvious to you that I could try.
As I said, it is a version of the latest idmconsole example of seam-security, customised for glassfish.

I noticed what is said about that on the compatibility page

It seems that the problem have been noticed, but no issue declared and the link for the example kick a 404 error :( 

Since there is no issue declared, I must assume nobody is working on the subject ... :S