[JCA/JBoss] - WrapperDataSourceService
by myles_na_gopaleen
Hi. the invoke() method of this MBean (org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService) deems it illegal access if the JDBC object associated with the invocation cannot be found in its respective local map (where it was cached when it was created). I'm doing load tests of a web app and what I'm seeing is that the MBean is allowing more that one client to obtain a remote reference to a JDBC object while it is already in use by another and before the first client has called close() (which removes the object from the service cache). For instance, two clients get a remote reference to the same Statement. ClientA closes the statement. The statement is removed from the cache. Now any method ClientB invokes via his reference is illegal. I've enhanced the MBean logging. This excerpt bears out what I've described.
2006-10-30 09:43:11,637 DEBUG Created Statement proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=ImagearcOracleDS, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
2006-10-30 09:43:11,637 DEBUG Created Statement proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=ImagearcOracleDS, cacheID=14134277 : thread=RMI TCP Connection(6)-xx.xx.x.xxxx
2006-10-30 09:43:11,637 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract void java.sql.PreparedStatement.setInt(int,int) throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
2006-10-30 09:43:11,637 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract java.sql.ResultSet java.sql.PreparedStatement.executeQuery() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
2006-10-30 09:43:11,668 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract void java.sql.PreparedStatement.setInt(int,int) throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(4)-xx.xx.x.xxxx
2006-10-30 09:43:11,684 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract int java.sql.Statement.getMaxRows() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(6)-xx.xx.x.xxxx
2006-10-30 09:43:11,684 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract int java.sql.Statement.getQueryTimeout() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
2006-10-30 09:43:11,684 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract void java.sql.Statement.close() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
2006-10-30 09:43:11,684 DEBUG Closed Statement=14134277
2006-10-30 09:43:11,699 DEBUG SQLException : executeQuery : Failed to find Statement : cacheID=14134277 : thread=RMI TCP Connection(4)-xx.xx.x.xxxx
2006-10-30 09:43:11,715 DEBUG SQLException : getMaxRows : Failed to find Statement : cacheID=14134277 : thread=RMI TCP Connection(1)-xx.xx.x.xxxx
2006-10-30 09:43:11,824 DEBUG SQLException : close : Failed to find Statement : cacheID=14134277 : thread=RMI TCP Connection(1)-xx.xx.x.xxxx
The app is deployed in JBoss 4.0.2 and uses Hibernate (the version that ships w/JBoss) for persistence. I'm looking for an explanation and would appreciate any help. Thanks.
P.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982218#3982218
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982218
17 years, 5 months
[JBoss Seam] - EntityHome silently discards updates after errors
by cja987
In the framework, I'm trying to enforce optimistic locking and a unique constraint on the "name" attribute. For optimistic locking, there's not a lot I can do except kick them out (they can always open a new window and use their back button to copy their changes and merge them in). For name conflicts, I thought to add a message and let them try something else.
Here's the code:
| @End @Transactional @Override
| public String update() {
| getInstance().setUpdatedOn(new Date());
| try {
| return super.update();
| } catch (OptimisticLockException e) {
| facesMessages.add("#{messages.staleEditRule}");
| return "aborted";
| } catch (EntityExistsException e) {
| facesMessages.add("name", "#{messages.errNameExists}");
| return null;
| } catch (RuntimeException e) {
| facesMessages.add(e.toString());
| return null;
| }
| }
|
Only problem is, this appears to work -- you correct the name, hit update, your changes appear to take, you're back in the view screen -- but when you next view the entity you edited, you find your changes never actually took.
I think I understand why this is happening -- the session is no longer valid after an exception -- but there's no indication even in log messages that this has happened, and the update was just silently dropped.
So I have two questions:
1) Is the lost update detectable somehow? I feel like EntityManager should have screamed at me for trying to update again after the exception, but it gave nary a peep.
2) How do I gracefully recover from errors on update and reset the entityManager so further updates can succeed? Should I make the unique constraint a validator instead? Enforcing unique constraints must be a FAQ for Hibernate, but I haven't found an answer yet.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982209#3982209
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982209
17 years, 5 months