Re: [JBoss-dev] resource-ref & resource-managers in jboss.xml
Ok, I see some utility in that although a global search/replace is still easier for my money. It would be easy to allow for direct specification of the jndi binding under the session/resource-ref element via a jndi-name element while still allowing for the use of the resource-name indirection if desired. The content model would change from: to > > My understanding is that the purpose of the double indirection is to make the > case where you have many beans and many resources in the the one file more > manageable. > > describes what the resource *does* > describes what the resource is *called* > describes where the resource is *located* > > During development all of your resource might be located in the one DBMS, e.g. > HSQL or something. In production you might choose to separate the inventory > database to an external Oracle instance, but leave the product and accounts > databases running somewhere else. > > I agree that the double indirection causes a lot of confusion. Perhaps we can > make it optional? > > Toby. > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
I was about to tackle the most significant performance related problem in JAWS (see the discussion and feature request on "CMP and finders: optimized" and "optimize collection finders", respectively) I've been building database applications for quite a while now (damn near the only thing i've ever done, software-wise) and am willing to take this task on. More comments follow in-line. marc fleury wrote: > OK, > > I now believe that I am staring at a simple fact. The PERFORMANCE IN > CONTAINERS IS BOLONEY! > > Our container can run in 0.05ms (yes **m**s) and still excercise 80 of its > features. what costs a lot is **serialization** and we find that in JDBC > calls and network calls. > > It appears that our JDBC calls are not optimized at all. We know it is just > JawsCMP but it is what people really look at when they work on JBoss. There > are tons of optimizations such as using "raw" ids in the database (Oracle). > The way we would work this is that we could then map the primary keys to the > raw ID (simple map) and the lookups would be kick ass fast. As a first step here, I'll make the 'command factory' used by JAWS for a container configurable. This will make it easier to make DBMS specific implementations of certain commands. > > I believe we also implement correctly the "isModified", but we could really > do a "getModified" that would return the names of the modified fields. We > could then bypass the "tuned" updates. Personally, I'd rather keep the 'tuned' updates code, since it requires no-more container specific code. What's done now mirrors the behavior of Borland's CMP implementation, which is a very developer-friendly system. What do you see that's bad in the tuned updates? > > Finally the load today is very blind and very stupid. We just load > everyone. A simple implementation of the "versioning" pattern in the > database (where we add a field that is the version of the record) enables us > to get the right version in little time and saves us time in loading since > we can just "select version where rawID" for example :) This is a fine optional feature. I've implemented this in BMP beans and it shouldn't be too hard to add. > > If you are interested in leading this effort and have serious db background > please let the board know > > marc > > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] resource-ref & resource-managers in jboss.xml
On Sun, May 06, 2001 at 08:03:42PM -0700, Scott M Stark wrote: > We use a double indirection layer to resolve the JNDI name for an >ejb-jar/resource-ref > element and I don't see why this can't be handled by a single layer. For example, >given > a javax.sql.DataSource reference in an ejb-jar like > > > > > TheSession > ... > > jdbc/MyDS > javax.sql.DataSource > Contaner > > > > > > requires a jboss.xml descriptor like the following to map this to java:/DefaultDS > > > > > TheSession > > jdbc/MyDS > DefaultDS > > > > > > > DefaultDS > java:/DefaultDS > > > > > But the resource-managers/resource-manager really only specifies res-jndi-name value. > Why not simply allow the following and drop the use of resource-managers? My understanding is that the purpose of the double indirection is to make the case where you have many beans and many resources in the the one file more manageable. describes what the resource *does* describes what the resource is *called* describes where the resource is *located* During development all of your resource might be located in the one DBMS, e.g. HSQL or something. In production you might choose to separate the inventory database to an external Oracle instance, but leave the product and accounts databases running somewhere else. I agree that the double indirection causes a lot of confusion. Perhaps we can make it optional? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] resource-ref & resource-managers in jboss.xml
We use a double indirection layer to resolve the JNDI name for an ejb-jar/resource-ref element and I don't see why this can't be handled by a single layer. For example, given a javax.sql.DataSource reference in an ejb-jar like TheSession ... jdbc/MyDS javax.sql.DataSource Contaner requires a jboss.xml descriptor like the following to map this to java:/DefaultDS TheSession jdbc/MyDS DefaultDS DefaultDS java:/DefaultDS But the resource-managers/resource-manager really only specifies res-jndi-name value. Why not simply allow the following and drop the use of resource-managers? TheSession jdbc/MyDS java:/DefaultDS ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JBoss daily test results SUMMARY Number of tests run: 63 Successful tests: 56 Errors:3 Failures: 4 DETAILS OF ERRORS Suite: org.jboss.test.cts.test.AllJUnitTests Test:testRemoveSessionObject Type:failure Exception: junit.framework.AssertionFailedError Message: [EJB 1.1, p42] Expected 'RemoveException', detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) Stack Trace: junit.framework.AssertionFailedError: [EJB 1.1, p42] Expected 'RemoveException', detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(StatefulSessionTest.java:187) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testProbeBeanContext Type:failure Exception: junit.framework.AssertionFailedError Message: Caught an unknown exception in testProbeBeanContex Stack Trace: junit.framework.AssertionFailedError: Caught an unknown exception in testProbeBeanContex at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testProbeBeanContext(StatefulSessionTest.java:466) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:202) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:326) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testEjbRemove Type:failure Exception: junit.framework.AssertionFailedError Message: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. Stack Trace: junit.framework.AssertionFailedError: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.BmpTest.testEjbRemove(BmpTest.java:224) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at
Re: [JBoss-dev] TODO: Deployer
On Sun, May 06, 2001 at 09:09:28PM -0400, marc fleury wrote: > Ok, > > copying the file is a necessary thing but it also completely kills our > performance in deployment. > There has got to be a better way as it is killing us with big files. Yes I > know it is the class loaders and the hot-deploy feature but we need to find > a way. Why does it take so long to copy a file? Is this a problem with the way we implement file copying, or what? That said, it might be a better idea to tackle the reasons why we have to copy in the first place. Does someone have a quick summary of these reasons? The RARDeployer copied RAR files because there's something screwy with JarURLConnection that means that I can't open the same RAR file twice. > Also this deployer is in bad need of a serious refresh... I must apologise for volunteering to do this and then not producing anything. What happened to the stuff you, Rickard and Dr Jung were working on? I thought the last prototype from Dr Jung that I saw was looking promising. I'm not prepared to spare enough time to tackle this in the near future, but I'm very keen to see someone else do it :-). Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml or jaws.xml?
On Sun, May 06, 2001 at 09:09:39PM -0400, marc fleury wrote: > Ok, > > I read a lot of confusion here, and I am very confused. > > Short answer, it belongs in jboss.xml. Short disagreement, no it doesn't. Although I think this is actually what you argue for in the long answer. > However first things first. We do not implement transaction isolation > settings on the database connections we get (do we?). I want to understand > how to implement it. > > Re: Transaction isolation level. It is a JDBC only call and we set it once > on the connection. The database isolates the *records* that are accessed by > the application server by enrolling these in the transaction that is running > and releasing the records when the transaction is done. > > It is then my understanding that when a driver enrolls a resource it must do > so through the XA protocols and I am fuzzy as to who registers the XA > resource in the ongoing transaction. Do the minerva pools make sure that if > there is a JBoss transaction then we register a listener? Yes. If you look in XAPoolDataSource or somesuch then it asks the transaction manager for the current transaction and enlists an XAResource with it. > Do the connectors provide a unified way to do this, how do they map to say a > Oracle driver or a postgreSQL driver. This is what javax.sql.XADataSource is for, abstracting this out. Things are complicated by the fact that almost nobody has a JDBC driver that implements the javax.sql stuff properly. Hence Minerva's XADataSourceImpl et. al., which just fake it. > Another question I have is the following: what is the default isolation > level set on databases with JDBC? I would imagine that since there is very > little usage of JTS infrastructure that there is *very* spotty support for > the stuff I described... jdbc is such a mess. I think the default isolation level is vendor-specific (i.e. there is none). This is unrelated to JDBC driver support. > Simply speaking, we can define the transaction isolation tag in jboss.xml > that is the easy part, what we do with it is still a bit of a mistery... I > am not surprised that Mad Andy couldn't get it to work in WebLogic. > > |> Does anyone have opinions on whether this would be a good feature or > |> not? The 1.1 spec does not specify how isolation levels should be > |> handled, except for BMT session beans, and by saying/implying that beans > |> can call resource manager specific APIs to set it themselves (carefully). > > sure, still how does the driver listen for the JBoss demarcation, if someone > can explain that clearly to me it would be great. But to answer your > question directly, I would say that *possibly* CMT/CMP is the only one where > we *need* to specify the isolation level. The JCA spec spells out how connections get enlisted in the appropriate transaction. Essentially, when the application asks the connection factory, e.g. javax.sql.DataSource, for a connection, the connection factory calls back to the application server through the ConnectionManager interface. This is how the app server hooks in its "quality of services" such as connection pooling, security and transactions. > |What do mean by "cover BMP and CMP entities as well as sessions"? This > |can only apply to JDBC connections, right? Do you propose to set the > > Yes, > > |isolation level when a connection handle is obtained by the bean? If > > In case of CMP/BMP whenever we obtain a connection we need to set the > isolation levels on it. We would need to put these calls in the CMP code > for jaws and we can set it ourselves (explicit call). In the case of BMP it > is a bit more complicated as the only indirection that we have is that one > that comes out of the naming and the one in the pools which are today > minerva. We would need to either find the wrapper JCA approach to do it > with JBoss or pass jboss.xml information to minerva. Again, in both cases, > I am interested in hearing clearly how this is implemented by the driver > vendors (does postgresSQL support this for example) As far as I'm concerned, JCA is the only way to get resource connections. This means that we can simply hook in at the ConnectionManager. > Also I find myself wondering if a BMP call should not be set by the bean > directly... i.e. let's NOT go through 1000 lines of code to save the bean > developer **1** line. Agree. > |so, this should probably be implemented using the same mechanism I have > |in mind to implement beans hanging onto connection handles across > |transactions. > | > |JBossCX defines the JBossConnectionListener interface for this purpose, > |although it is not currently used. The idea is that when a resource > |adapter gives out a connection handle, the app server is notified so > |that it can make sure it is participating in the correct transaction. > |It would be easy to extend that to any transaction-specific setup we > |wanted to do. > > Ok so in that indirected code the appserver
RE: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml or jaws.xml?
Ok, I read a lot of confusion here, and I am very confused. Short answer, it belongs in jboss.xml. However first things first. We do not implement transaction isolation settings on the database connections we get (do we?). I want to understand how to implement it. Re: Transaction isolation level. It is a JDBC only call and we set it once on the connection. The database isolates the *records* that are accessed by the application server by enrolling these in the transaction that is running and releasing the records when the transaction is done. It is then my understanding that when a driver enrolls a resource it must do so through the XA protocols and I am fuzzy as to who registers the XA resource in the ongoing transaction. Do the minerva pools make sure that if there is a JBoss transaction then we register a listener? Do the connectors provide a unified way to do this, how do they map to say a Oracle driver or a postgreSQL driver. Another question I have is the following: what is the default isolation level set on databases with JDBC? I would imagine that since there is very little usage of JTS infrastructure that there is *very* spotty support for the stuff I described... jdbc is such a mess. Simply speaking, we can define the transaction isolation tag in jboss.xml that is the easy part, what we do with it is still a bit of a mistery... I am not surprised that Mad Andy couldn't get it to work in WebLogic. |> Does anyone have opinions on whether this would be a good feature or |> not? The 1.1 spec does not specify how isolation levels should be |> handled, except for BMT session beans, and by saying/implying that beans |> can call resource manager specific APIs to set it themselves (carefully). sure, still how does the driver listen for the JBoss demarcation, if someone can explain that clearly to me it would be great. But to answer your question directly, I would say that *possibly* CMT/CMP is the only one where we *need* to specify the isolation level. |What do mean by "cover BMP and CMP entities as well as sessions"? This |can only apply to JDBC connections, right? Do you propose to set the Yes, |isolation level when a connection handle is obtained by the bean? If In case of CMP/BMP whenever we obtain a connection we need to set the isolation levels on it. We would need to put these calls in the CMP code for jaws and we can set it ourselves (explicit call). In the case of BMP it is a bit more complicated as the only indirection that we have is that one that comes out of the naming and the one in the pools which are today minerva. We would need to either find the wrapper JCA approach to do it with JBoss or pass jboss.xml information to minerva. Again, in both cases, I am interested in hearing clearly how this is implemented by the driver vendors (does postgresSQL support this for example) Also I find myself wondering if a BMP call should not be set by the bean directly... i.e. let's NOT go through 1000 lines of code to save the bean developer **1** line. |so, this should probably be implemented using the same mechanism I have |in mind to implement beans hanging onto connection handles across |transactions. | |JBossCX defines the JBossConnectionListener interface for this purpose, |although it is not currently used. The idea is that when a resource |adapter gives out a connection handle, the app server is notified so |that it can make sure it is participating in the correct transaction. |It would be easy to extend that to any transaction-specific setup we |wanted to do. Ok so in that indirected code the appserver is notified of the fact the connection was handed out and I assume that the connection object is passed to the container. You would have to cast that connection to a "JDBC" connection and set the isolation levels on it. The locking is clearly an application level issue (lock these records like this) since the same connection can access different records we set the isolation at the container level ** with app knowledge** and that is controlled by JBoss. In case of CMP we can set the transaction isolation levels in the jaws code, we are in the body of the container code (CMP) and we can take a look at the isolation levels passed by the jboss.xml. In case we are BMP... it becomes really complex since the bodies of code where we can indirect (the naming and the container notification you show in JCA) have **no** knowledge of the application flow (or does JCA know?)... in ANY case, I would argue that in case of ***BMP*** we SHOULD'NT set anything ourselves and if I remember the spec correctly (but these memories get fuzzy) we must NOT set anything in BMP... the user does it ... one freaking line in his body of code. CMP' case is trivial. We just go in the JAWS code where we "get" the connection and we set the isolation level (everytime?) on it. Again I would really appreciate someone explaining clearly to me the "under the hood" of how a driver listens for JBoss
[JBoss-dev] TODO: Option D
Ok, no refresh ever or a refresh all the time is a bit "bone-head" and there are "soft ball" requirements at the level of the cache. Option D, is when the cache is invalidated every X seconds, but in between the state is not reloaded which will GREATLY speed the container (because we avoid JDBC serialization) in most cases. The fact is that "hard ball" requirements, i.e. refreshing all the time, is kind of overkill and never refreshing is way under-kill. So I actually give that as an excercise in the "JBoss Training" that I am giving. It is really about 10 lines in the right interceptor... see if you guys can do it. Same... if you are interested let the board know. marc _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] TODO: Deployer
Ok, copying the file is a necessary thing but it also completely kills our performance in deployment. There has got to be a better way as it is killing us with big files. Yes I know it is the class loaders and the hot-deploy feature but we need to find a way. Also this deployer is in bad need of a serious refresh... if you are interested please notify the board. marc _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] TODO: URL JMX installation of JBoss
Ok, First todo, on the mailing list. We tried getting the "URL" installation working and frankly guys it was a mess. The scenario is simple, we want to be able to download JBoss from the web and just have the basic jboss-spine.jar on a diskette. Previously Rickard had a "run.jar" that just had the Main in it. Since then the server has grown and nothing works in remote fashion anymore. All the modules look for some configuration files on the file system and all that is broken. Also the ClassPathExtension is buggy as it doesn't seem to really see the remote server files (but maybe we are missing something). We did manage to get JBoss running from a URL (like we do run ). We also were able to use the configuration file from the webserver. This is already great as it means you can maintain centralized configurations of the server. It is not "polished". If someone is interested in taking ownership of that, i.e. making sure that we can install (always) a FARM of JBoss servers from a central webserver and please let the board know. marc _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] TODO: JBossCMP 1.1 FAST!
OK, I now believe that I am staring at a simple fact. The PERFORMANCE IN CONTAINERS IS BOLONEY! Our container can run in 0.05ms (yes **m**s) and still excercise 80 of its features. what costs a lot is **serialization** and we find that in JDBC calls and network calls. It appears that our JDBC calls are not optimized at all. We know it is just JawsCMP but it is what people really look at when they work on JBoss. There are tons of optimizations such as using "raw" ids in the database (Oracle). The way we would work this is that we could then map the primary keys to the raw ID (simple map) and the lookups would be kick ass fast. I believe we also implement correctly the "isModified", but we could really do a "getModified" that would return the names of the modified fields. We could then bypass the "tuned" updates. Finally the load today is very blind and very stupid. We just load everyone. A simple implementation of the "versioning" pattern in the database (where we add a field that is the version of the record) enables us to get the right version in little time and saves us time in loading since we can just "select version where rawID" for example :) If you are interested in leading this effort and have serious db background please let the board know marc _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml or jaws.xml?
On Sun, May 06, 2001 at 09:35:43AM -0400, David Jencks wrote: > Hi, > I'm confused. Are you saying that the behavior mandated by the JCA spec is > not sufficient to guarantee that every connection handle will used in the > correct transaction? If so, is this not a deficiency in the spec? If not, > what is the JBossConnectionListener for more specifically? JBossConnectionListener is part of the contract between JBossCX and a connection manager, such as those provided by Minerva. This contract is not part of the JCA spec because it is considered part of the application server. Toby. > thanks > David Jencks > > On 2001.05.05 23:51:29 -0400 Toby Allsopp wrote: > > danch wrote: > > > > > Does anyone have opinions on whether this would be a good feature or > > > not? The 1.1 spec does not specify how isolation levels should be > > > handled, except for BMT session beans, and by saying/implying that > > beans > > > can call resource manager specific APIs to set it themselves > > (carefully). > > > > > > If this seems like a good idea, should this setting be in jboss.xml > > (and > > > cover BMP and CMP entities as well as sessions), or in jaws.xml > > > (covering _only_ CMP entities, since others are free to call the > > > resource manager's APIs)? > > > > What do mean by "cover BMP and CMP entities as well as sessions"? This > > can only apply to JDBC connections, right? Do you propose to set the > > isolation level when a connection handle is obtained by the bean? If > > so, this should probably be implemented using the same mechanism I have > > in mind to implement beans hanging onto connection handles across > > transactions. > > > > JBossCX defines the JBossConnectionListener interface for this purpose, > > although it is not currently used. The idea is that when a resource > > adapter gives out a connection handle, the app server is notified so > > that it can make sure it is participating in the correct transaction. > > It would be easy to extend that to any transaction-specific setup we > > wanted to do. > > > > Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss/servlet container test suite???
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > I see two problems with how web containers are integrated into > JBoss due to the lack > of a web container integration interface/mbean. The first problem > is that there is no JBoss > component that is parsing the jboss-web.xml file to handle JNDI > mapping. The second > problem is no support for using the JBoss security domains across > both the web and ejb > components in an ear. I'm going to look into providing this. Someone recently (within the past week) posted a Tomcat realm that delegated to the jBoss security. jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RFC: Add isolation level attribute in jboss.xml or jaws.xml?
Hi, I'm confused. Are you saying that the behavior mandated by the JCA spec is not sufficient to guarantee that every connection handle will used in the correct transaction? If so, is this not a deficiency in the spec? If not, what is the JBossConnectionListener for more specifically? thanks David Jencks On 2001.05.05 23:51:29 -0400 Toby Allsopp wrote: > danch wrote: > > > Does anyone have opinions on whether this would be a good feature or > > not? The 1.1 spec does not specify how isolation levels should be > > handled, except for BMT session beans, and by saying/implying that > beans > > can call resource manager specific APIs to set it themselves > (carefully). > > > > If this seems like a good idea, should this setting be in jboss.xml > (and > > cover BMP and CMP entities as well as sessions), or in jaws.xml > > (covering _only_ CMP entities, since others are free to call the > > resource manager's APIs)? > > What do mean by "cover BMP and CMP entities as well as sessions"? This > can only apply to JDBC connections, right? Do you propose to set the > isolation level when a connection handle is obtained by the bean? If > so, this should probably be implemented using the same mechanism I have > in mind to implement beans hanging onto connection handles across > transactions. > > JBossCX defines the JBossConnectionListener interface for this purpose, > although it is not currently used. The idea is that when a resource > adapter gives out a connection handle, the app server is notified so > that it can make sure it is participating in the correct transaction. > It would be easy to extend that to any transaction-specific setup we > wanted to do. > > Toby. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Added support for handles to "remember" their container
Hello Jason, > I looked over it very briefly. As I remember, it was not in CVS, which > made it a bit more difficult to look at. I do plan on looking at it. Are > there any plans to integrate the HA stuff into the main JBoss branch? Complete source code is available for download (a few ko) from the web site previously mentionned. It will most probably commited in the future JBoss 3.0 CVS branch (most probably after some enhancements though). > If this is going to be added soon, then we can sync up on ideas about > proxy/handles. How did you handle JNDI interaction? Is is jnp specific? In fact, it is source-server-specific i.e. it will use the provider used on the particular server it is trying to reconnect. In general, all server will use the same provider. Though, I do not think I updated the handle code, only the proxy. For now, I do not have time to continue with the HA stuff. Nevertheless, I plan to propose a document to the joss-dev ML with architecture propositions. Any feedback is welcome. Cheers, Sacha > --jason > > On Wed, 2 May 2001, Sacha Labourey wrote: > > > Hello Jason, > > > > > I also wanted to share some ideas that I had on how to use the > > > modifications > > > that I made with HA or auto-generated env properties. > Basically I think > > ... > > > in a HA aware InitialContextHandle impl that would use jini, > raw multicast > > > or whatever to find a suitable container. > > > > > > If anyone else has any ideas on the matter I would like to hear > > > them. If I > > > do not hear anything that I think I will work on implementing > the above. > > > > Have you tried my implementation of HA for SLSB? > > (http://194.38.95.241/jboss/) > > > > It already implements a possible solution to this issue. > > > > In some words (nothing would be more accurate than testing it > and reading at > > the proxy code ;) ), all possible JBoss instances share HA > information such > > as bean location, ... When creating the proxy from the > container, we give > > him information about all possible "targets" (i.e. JBoss instances > > containing a replica of the same bean than the current proxy > being built). > > > > The proxy is then able to use all these different targets when > performing > > invocations (or home lookup, create calls, ...) Furthermore, the current > > proxy implementation is able to "resynch" its state with the > JBoss cluster > > (i.e. set of JBoss instances) to update its list of targets (to take in > > account, for example, newly started nodes). > > > > Cheers, > > > > > > > > Sacha > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
