[Design of JBossCache] - Re: Custom data versions
by bstansberry@jboss.com
This discussion relates to https://jira.jboss.org/jira/browse/JBCACHE-1250 as well
Quoting myself from my first comment on that JIRA:
"Main reason I want to keep the structural node around are 1) it's marked as "resident" and 2) if OPTIMISTIC it has a special DataVersion that never reports conflicts. Without that DataVersion I get OL conflicts. If I let the structural node get reestablished via a regular put for a child, it ends up with regular data version."
Re: 2)
The discussion above may remove the DataVersion issue. The DataVersionProvider interface allows me to ensure the correct DataVersion is applied to the resident node. I say "may" because it only solves the problem if the DataVersion is properly passed around the cluster, works with invalidation etc. Haven't thought hard about that.
Further, looking at the analysis of data versions on this thread, I think what is really needed for the Hibernate case is to disable the data versioning for OL. That is, allow configuration of a cache-wide DataVersionFactory, where Hibernate would configure a factory that returns its NonLockingDataVersion. There doesn't seem to be any advantage to actually doing version validation. Either Hibernate will catch any version conflict at the DB level before the JBC beforeCompletion() callback gets invoked, or a PFER will see any existing node and abort.
Re: 1)
TBH, I'm not sure if there's any reason I care about the node being marked "resident" other than its relation to the DataVersion issue. IIRC "resident" basically means it doesn't get evicted, and I *think* the only reason I care about eviction is I lose the custom DataVersion. But let's assume I do have a reason to care, or someone else does. Perhaps the DataVersionProvider concept discussed above should be expanded to handle all such "NodeMetaData":
| public interface NodeMetaDataProvider() {
|
| NodeMetaData getNodeMetaData(Fqn fqn);
|
| }
|
| public interface NodeMetaData {
|
| /** Get the desired DataVersion for the node. A return value of null means use the default mechanism for determining the DataVersion */
| DataVersion getDataVersion();
|
| /** Should the node be marked as resident? */
| boolean isResident();
|
| .... for any similar metadata
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168170#4168170
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168170
15 years, 8 months
[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions
by adrian@jboss.org
"jesper.pedersen" wrote : Sounds like a good idea - if you want to take a look see the org.jboss.resource.adapter.jdbc package.
|
| That being said - we are about to start a new implementation of the JCA container where we will keep this feature request in mind.
| Thanks !
This would be a policy on the connection manager not the adapter.
It would be handled in BaseConnectionManager2::connectionErrorOccurred()
by invoking the pool.
Like Jim, I'd propose three options
* Failing connections only - what we do now
* Idle connections - i.e. just do pool.flush()
* All connections - invoke returnManagedConnection(true) on all the connections in the pool(s) regardless of whether they are in use or not.
I don't like the last one because unless it is a real database failure rather than
a transient failure on one connection, you're failing far more transactions than you should.
It would be better to let the ExceptionSorter trap whether there are real failures
to those in use connections.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168167#4168167
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168167
15 years, 8 months
[Design of POJO Server] - Re: Diff behavior with diff AnnotatedMetaDataDeployer
by alesj
"alesj" wrote : I know what the problem is, and what the proper fix should look like.
|
Fixed, and it works like a charm :-)
| 2008-08-01 14:54:30,625 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Annotated classes [vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-booking.ear/jboss-seam.jar, org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator@146a226]: [class org.jboss.seam.security.NotLoggedInException, class org.jboss.seam.security.AuthorizationException, class org.jboss.seam.framework.EntityNotFoundException, class org.jboss.seam.async.TimerServiceDispatcher, class org.jboss.seam.transaction.EjbSynchronizations]
|
| 2008-08-01 14:54:30,578 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Annotated classes [vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-booking.ear/jboss-seam-booking.jar, org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator@7962ea]: [class org.jboss.seam.example.booking.ChangePasswordAction, class org.jboss.seam.example.booking.AuthenticatorAction, class org.jboss.seam.example.booking.RegisterAction, class org.jboss.seam.example.booking.HotelSearchingAction, class org.jboss.seam.example.booking.BookingListAction, class org.jboss.seam.example.booking.HotelBookingAction]
|
| 2008-08-01 14:54:30,562 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Annotated classes [vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-booking.ear/jboss-seam-booking.war, org.jboss.metadata.annotation.creator.web.Web25MetaDataCreator@a72445]: []
|
| 2008-08-01 14:54:30,546 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Annotated classes [vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-booking.ear, org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator@5fb7c4]: []
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168157#4168157
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168157
15 years, 8 months