August 2008 - jboss-dev-forums - Jboss List Archives

[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions

by vickyk

"adrian(a)jboss.org" wrote : | * Idle connections - i.e. just do pool.flush() | How about Failing Connection + Idle Connections here ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168174#4168174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168174

15 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Exception serializing DeploymentUnit

by bstansberry＠jboss.com

Thanks for the reminder! I meant to ask about that, but got distracted and forgot. I'll move them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168173#4168173 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168173

15 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions

by jesper.pedersen

I agree with Adrian. The ExceptionSorter and ValidConnectionChecker functionality we have today provide an excellent starting point in this area. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168172#4168172 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168172

15 years, 8 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions

by jesper.pedersen

Jim, we can implement different policies on the pool in the new JCA implementation. Then it is just to add an implementation for the specified interface and configure it. The current JCA implementation uses ExceptionSorter and ValidConnectionChecker as described in the documentation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168166#4168166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168166

15 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions

by cbredesen

https://jira.jboss.org/jira/browse/JBAS-5824 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168165#4168165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168165

15 years, 8 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions

by jim.moran＠jboss.com

Why not have 3 settings? EntirePool, FailedConnectionOnly, AND UnusedConnectionsOnly What is the point of closing in-use connections since the connection would throw an exception on the next call anyway if it is bad? There is no added benefit to closing the in-use connection but there is a potential negative if for some reason the connection is still good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168161#4168161 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168161

15 years, 8 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBossCache] - Re: Service threads

by manik.surtani＠jboss.com

Regarding disabling the eviction thread by setting WakeupIntervalSeconds to 0, this is done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168153#4168153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168153

15 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008