[JBoss-user] DatabaseServerLoginModule, and column RoleGroup
We are exploring using JBossSX in various capacities to perform database-driven authentication and authorization. I have a question about the DatabaseServerLoginModule: The "roles" table requires three columns: Principal, Role, and RoleGroup. However, I can find no clear explanation online for the purpose of the RoleGroup column, and every example I find always has the string value "Roles" inserted into the RoleGroup column. Is there ever a useful reason why we would put anything in that column, other than the string "Roles"? Thank you, Bryan
Re: [JBoss-user] failed lookup: java:comp/UserTransaction fromTomcat
Thanks Scott. I'll try that! Bryan On Fri, 2003-06-20 at 00:44, Scott M Stark wrote: This has been fixed in the 3.2 branch. To get the ENC namespace to be visible in the 3.2.2RC1 set the UseJBossWebLoader attribute to false in the jbossweb-tomcat41.sar/META-INF/jboss-service.xml descriptor. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bryan Field-Elliot To: [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 12:21 PM Subject: [JBoss-user] failed lookup: java:comp/UserTransaction from Tomcat I've been using JBoss 3.0.6+Tomcat 4.1.18 for development, and just upgraded to JBoss 3.2.2RC1 + Tomcat 4.1.24. Code which previously worked, now suddenly isn't... Specifically, my servlet is trying to look up "java:comp/UserTransaction", and failing. I do not have any references to UserTransaction in either my web.xml, or in jboss-service.xml. Am I supposed to? (if so, this must be a new requirement in JBoss 3.2). Thanks, Bryan
follow-up Re: [JBoss-user] failed lookup: java:comp/UserTransactionfrom Tomcat
Evidently, changing my lookup from "java:comp/UserTransaction" to just "UserTransaction" works... The follow-on question is, is this standard? This seems like moving away from standard J2EE syntax, unless I'm missing something else... I thought I needed to look up these things in "java:comp/" or "java:comp/env/". Thanks, Bryan On Tue, 2003-06-17 at 13:21, Bryan Field-Elliot wrote: I've been using JBoss 3.0.6+Tomcat 4.1.18 for development, and just upgraded to JBoss 3.2.2RC1 + Tomcat 4.1.24. Code which previously worked, now suddenly isn't... Specifically, my servlet is trying to look up "java:comp/UserTransaction", and failing. I do not have any references to UserTransaction in either my web.xml, or in jboss-service.xml. Am I supposed to? (if so, this must be a new requirement in JBoss 3.2). Thanks, Bryan
[JBoss-user] failed lookup: java:comp/UserTransaction from Tomcat
I've been using JBoss 3.0.6+Tomcat 4.1.18 for development, and just upgraded to JBoss 3.2.2RC1 + Tomcat 4.1.24. Code which previously worked, now suddenly isn't... Specifically, my servlet is trying to look up "java:comp/UserTransaction", and failing. I do not have any references to UserTransaction in either my web.xml, or in jboss-service.xml. Am I supposed to? (if so, this must be a new requirement in JBoss 3.2). Thanks, Bryan
[JBoss-user] Someone PLEASE advise re: Client UserTransactions never commiting
I am hoping someone can help me solve a problem I'm having with JBoss 2.4.4 (using RedHat Linux 7.1 and PostgreSQL 7.0.2). My client application manipulates several entity beans. I know that a better design would be to use a session facade, but that's not an option in the short term. In any case -- I've introduced the use of UserTransaction from the client. I obtain a UserTransaction and call "begin". Then I manipulate my entity beans. Finally, I call "UserTransaction.commit()". My changes are being written to the database, but, they are not being commited. I know this because when my application tries to read the values back, the new values are shown. But another application, connecting directly to PostgreSQL, shows the old values. Lastly, when I restart JBoss or reload the EAR file, all the old values come back. My CMP beans are marked as "Requires" a transaction. Can anyone please help me deduce what's going wrong, and why my commit() calls don't seem to be doing anything? Thank you, Bryan
[JBoss-user] Please help re: Client-side UserTransactions not commiting
I am hoping someone can help me solve a problem I'm having with JBoss 2.4.4 (using RedHat Linux 7.1 and PostgreSQL 7.0.2). My client application manipulates several entity beans. I know that a better design would be to use a session facade, but that's not an option in the short term. In any case -- I've introduced the use of UserTransaction from the client. I obtain a UserTransaction and call "begin". Then I manipulate my entity beans. Finally, I call "UserTransaction.commit()". My changes are being written to the database, but, they are not being commited. I know this because when my application tries to read the values back, the new values are shown. But another application, connecting directly to PostgreSQL, shows the old values. Lastly, when I restart JBoss or reload the EAR file, all the old values come back. My CMP beans are marked as "Requires" a transaction. Can anyone please help me deduce what's going wrong, and why my commit() calls don't seem to be doing anything? Thank you, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] JB2.4.4 Client UserTransactions won't commit
Hi, I'm using JBoss 2.4.4. I have a set of CMP beans whose transaction attributes are all "Required". On the client side, I am obtaining a UserTransaction, calling begin(), making some CMP bean changes, and calling commit(). The changes do seem to make it to the database, since when I read the values back, they are changed. However, they never seem to be commited. Other processes which access my DB directly see the old data, and when I restart JBoss (or reload the ejb-jar file), all the database changes are lost. Is there something I might be doing wrong? I am certain I am calling UserTransaction.commit() at the end of my client processing, but it doesn't seem to be doing it. Thank you, Bryan
[JBoss-user] jboss.xml DTD missing from jboss.org website
The standard URL for the jboss.xml DTD, at: http://www.jboss.org/j2ee/dtd/jboss.dtd Appears to not be on the server -- has the "official" location been changed? Thank you, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] In-browser Java applet client to jBoss?
The strategy of building an EJB client out of a Java applet which uses RMI to communicate directly with an EJB server is (IMHO) technically elegant, but not very popular. I am wondering if people have tried it with jBoss with success and with stories to tell? This is in a Joe-Public-Internet-User scenario. We don't need to rehash the standard "firewall issues" with RMI; I think those issues are pretty well established. What I'm more concerned with are questions like: 1. What's the footprint of the client files needed? Is there a .Jar file within jBoss specifically meant for clients? Is it too big that the average public Internet user would get annoyed downloading it? 2. Does it function well on various Java-enabled browsers, such as different versions of MSIE, Netscape, Mozilla, etc? 3. What if the client's browser's JDK is 1.2, but my jBoss server's JDK is 1.3? Any issues there? 4. Is this just a bad idea in general, and should a rich-client applet be communicating via HTTP and a Servlet (and perhaps XML or SOAP), as opposed to RMI directly? Opinions appreciated, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: More Re: [JBoss-user] When do entity beans commit?
Hi Georg, Regarding this problem I've been having -- thank you for all your thoughts and help. I have no idea why the code was executing inside a transaction, since the session bean method was definitely marked Never, and the entity bean Supports. Perhaps this is a bug, or perhaps the "spec-undefined" behavior of Supports+Entity Beans within jBoss has changed. In any case -- I have given up. I completely re-wrote that section of code using straight JDBC calls directly from the session bean method (with no use of entity beans); it now runs faster and I'm not getting any deadlocks. Regards, Bryan Georg Rehfeld wrote: 050501c0f480$ebc632c0$[EMAIL PROTECTED]">Dear Bryan, 6. Log messages from server.log - yes this message seemed toappear many hundred times in a row, around the time of mydeadlock:[staffBean] LOCKING-WAITING (TRANSACTION) for id com.theApp.ejb.staffPK@73ctx.hash 2702560 tx:TransactionImpl:XidImpl[FormatId=257, GlobalId=app-web1//188, BranchQual=] This clearly indicates access to an instance INSIDE a transactionthat already is associated to another TX. Interesting would be toknow if only staffBean with PK 73 is logged, or if other beansare involved/logged, and then which Transaction Global Id isshown there.In a true deadlock scenario you should see one instance loggedwith (in your case) 73 + app-web1//188 and at least one otherwith some other PK and Global Id (say 42 + app-web1//4711), inyour case I expect both of type staffBean, but in complexerscenarios it could be of some other type. And the true deadlockcase could even involve more beans cyclic waiting for each other.If you only see 73 + app-web1//188 LOCKING-WAITING it's morelikely, that the instance is participating in a lengthyprocessing, so that TX app-web1//188 finally gives up, althoughnow true deadlock condition exists.But having said all this, you told us, that the sessions methodis 'Never' and the entity methods called are 'Supports', so youare right, there should be no transaction at all. And I assume,that, while your tests were running no intentional transactionalmethods were invoked?The last idea I can come up with is: might be you have a typo inyour deployment descriptor where you try to set your methods to'Supports' and thus they are left to the default 'Required'?Checked the CaSe too? I don't know, if this really is verified atdeployment time.If this even isn't the case, I would report this as a possiblebug at SourceForge, as nobody else came into this thread ofdiscussion to help us. Best you would provide more completeserver.log and your relevant deployment descriptor parts and codesamples (i.e. for others to have a true look at case and names ofmethods etc.)Ah, and a final note: the code around the LOCKING-WAITING and theException you receive was just reworked to solve some otherproblem. The modifying author (Bill Burke) said, this only is apartial attempt at the LOCKING-WAITING (he was focused on theother problem, which he solved) issue, but the JBoss founder MarcFleury is just about to rework that code even more.This modification(s) do nothing about the fact, that you seetransactional behaviour, where it shouldn't be (IMHO), but if theabove guess doesn't hold, you still may want to try the newversion out. It's only checked into CVS, so you had to compileJBoss yourself for a test. 4. Yes, conceivably some of the same entity beans are wanted byother threads at the same time as this thread is doing it'sthing. However I thought that, being non-transactional, therewouldn't be any contention problems. Maybe the calls areserialized, but at least there wouldn't be any deadlocks. Am Iwrong? As far as I understand the code version you are executing (2.2.1or 2.2.2 I assume, did you tell us?) there could be deadlock withnon-reentrant beans, at least when they actually do a callback(which would require reentrant to be enabled), but this would belogged differently, so in your case it doesn't seem to be thereason.Just to clarify (my favorite Sequence diagram again :-)sessionentity Aentity B--- I mA1 | | I-->ImB1| I I-->I I I I I ImA2I I II<-I <<< blocks foreverThis is due to a bug (I think) in JBoss in an attempt to be morewise than the EJB Spec, which requires an EJBException to bethrown when B calls back A via mA2 while A still is not finishedwith mA1 and the bean A isn't reentrant. JBoss instead would gointo a busy waiting loop for mA1 to finish, which doesn't happen.But I'm not really sure on this, just haven't the old codearound, and, oops, it's already again 5 a'clock in the morning,much too late to check the old source out and try to verify or doa test case now. If I turn out to be right, I SHOULD report thatas a bug (that code in EntityInstanceInterceptor is really tootricky to fiddle with, when unexperienced)!best regar
Re: More Re: [JBoss-user] When do entity beans commit?
Georg, About my environment -- 1. I do not use select...for update 2. Regarding other resources used concurrently -- just entity beans. And as I mentioned -- it's a session bean method marked "Never", which happens to iterate over a large list of entity beans (of several different types) to collect data. The entity beans are marked as "Supports", so as far as I can understand, there should be no transaction occuring. On the entity beans themselves, I'm only calling simple "get" methods (from within this particular session bean method). 3. Regarding lengthy operations -- yes it's sort of lengthy, only a few seconds though. 4. Yes, conceivably some of the same entity beans are wanted by other threads at the same time as this thread is doing it's thing. However I thought that, being non-transactional, there wouldn't be any contention problems. Maybe the calls are serialized, but at least there wouldn't be any deadlocks. Am I wrong? 5. The beans (both session and entity) are non-reentrant. I am not familiar with that setting with respect to EJB and not sure what consequences it would have, or whether I should be investigating it at this time. 6. Log messages from server.log - yes this message seemed to appear many hundred times in a row, around the time of my deadlock: [staffBean] LOCKING-WAITING (TRANSACTION) for id com.theApp.ejb.staffPK@73 ctx.hash 2702560 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=app-web1//188, BranchQual=] Further help would be appreciated Georg, thanks so much for taking the time. Bryan Georg Rehfeld wrote: 02ad01c0f394$5f724e90$[EMAIL PROTECTED]">Hello Bryan, In the scenario in which I describe below, I just got anotherdeadlock error from within a "read-only" method. The transactionexception details are:Name: javax.transaction.TransactionRolledbackExceptionMessage: Transaction marked for rollback, possibly a timeout; nested exception is: (omitted...)I thought that in the below scenario, there are no transactionsat work -- so how could it result in a deadlock, or be rolledback? Help would be appreciated, Difficult to guess from what you tell us. Do you use select forupdate, so that the DB causes deadlocks? Are there otherresources you try to access concurrenty? Is it possible that somebean does lengthy operations (or hangs) while others try toaccess the same bean instance? With non reentrant beans (default)no two clients can enter the same instance concurrently even outside of a transaction.Are there any log messages before theTransactionRolledbackException in the server.log that mightindicate whats going on? Your state charts of I's and dashes are awesome! Actually I tried to draw Sequence Diagrams, I find them helpfulsometimes. What I've done is mark all my Entity beans as "Supports", ratherthan "Requires".Furthermore, at the session bean level, my read-only methods aremarked as "Never", while my read/write methods are marked as"Requires".In this way I get good read-only performance for my read methods,and data integrity for my read/write methods.I am aware that marking my entity beans as "Supports" venturesinto "unspecified" behavior, but in the above scenario, itappears to work in a good way.If I am making a poor assumption here then I would appreciateyour further comments. I think, you do it, as I would have done it, as long as you areaware of the dirty/invalid data status and do not try to modifyanything based on it.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
More Re: [JBoss-user] When do entity beans commit?
In the scenario in which I describe below, I just got another deadlock error from within a "read-only" method. The transaction exception details are: Name: javax.transaction.TransactionRolledbackException Message: Transaction marked for rollback, possibly a timeout; nested exception is: (omitted...)I thought that in the below scenario, there are no transactions at work -- so how could it result in a deadlock, or be rolled back?Help would be appreciated,Bryan Bryan Field-Elliot wrote: [EMAIL PROTECTED]"> Thanks Georg, Your state charts of I's and dashes are awesome! Indeed I no longer saw deadlocks in that scenario, but I did see a performance slowdown, as every single "get" method resulted in the opening and closing of a transaction. What I've done is mark all my Entity beans as "Supports", rather than "Requires". Furthermore, at the session bean level, my read-only methods are marked as "Never", while my read/write methods are marked as "Requires". In this way I get good read-only performance for my read methods, and data integrity for my read/write methods. I am aware that marking my entity beans as "Supports" ventures into "unspecified" behavior, but in the above scenario, it appears to work in a good way. If I am making a poor assumption here then I would appreciate your further comments. Regards, Bryan Georg Rehfeld wrote: 024501c0f36d$c05a1d90$[EMAIL PROTECTED]">Hi Bryan, In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? As of the EJB spec 1.1 section 11.6.2 they are ended on returnfrom the Entities method set to Requires. I crosschecked the codein org.jboss.ejb.plugins.TxInterceptorCMT and it behaves as specified.session1session2entityA entityB--- ---| I TX.begin | || I-->I || I TX.commit | |I I | TX.begin |I->II I | TX.commit |I I | |I I | TX.begin |I I-->II I | TX.commit |I I TX.begin | |I->I |I I TX.commit | |Thus you should see no deadlock caused.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10- Original Message - From: "Bryan Field-Elliot" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Monday, June 11, 2001 11:06 PMSubject: [JBoss-user] When do entity beans commit? I am using jBoss 2.2.2.My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans.All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires".In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional?Help would be appreciated.Regards,Bryan___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user ___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] When do entity beans commit?
Thanks Georg, Your state charts of I's and dashes are awesome! Indeed I no longer saw deadlocks in that scenario, but I did see a performance slowdown, as every single "get" method resulted in the opening and closing of a transaction. What I've done is mark all my Entity beans as "Supports", rather than "Requires". Furthermore, at the session bean level, my read-only methods are marked as "Never", while my read/write methods are marked as "Requires". In this way I get good read-only performance for my read methods, and data integrity for my read/write methods. I am aware that marking my entity beans as "Supports" ventures into "unspecified" behavior, but in the above scenario, it appears to work in a good way. If I am making a poor assumption here then I would appreciate your further comments. Regards, Bryan Georg Rehfeld wrote: 024501c0f36d$c05a1d90$[EMAIL PROTECTED]">Hi Bryan, In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? As of the EJB spec 1.1 section 11.6.2 they are ended on returnfrom the Entities method set to Requires. I crosschecked the codein org.jboss.ejb.plugins.TxInterceptorCMT and it behaves as specified.session1session2entityA entityB--- ---| I TX.begin | || I-->I || I TX.commit | |I I | TX.begin |I->II I | TX.commit |I I | |I I | TX.begin |I I-->II I | TX.commit |I I TX.begin | |I->I |I I TX.commit | |Thus you should see no deadlock caused.regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10- Original Message - From: "Bryan Field-Elliot" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Monday, June 11, 2001 11:06 PMSubject: [JBoss-user] When do entity beans commit? I am using jBoss 2.2.2.My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans.All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires".In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional?Help would be appreciated.Regards,Bryan___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user ___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] When do entity beans commit?
I am using jBoss 2.2.2. My clients access a stateful session bean, and my session bean's methods in turn access CMP entity beans. All my entity beans are marked as "Requires" transactions; in my session bean, some methods are marked as "Never", while others are marked as "Requires". In the "Never" session bean methods, when exactly are my entity bean's transactions ENDED (committed)? These are essentially read-only methods in my session bean. They use entity beans to gather data, but they aren't making any changes. Nonetheless, they are causing me some deadlock problems. Will these entity beans not be released until after my session bean method returns, even though my session bean method is not transactional? Help would be appreciated. Regards, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Seeking advice on deadlock problem
Thanks Georg, that really clarifies a lot of things. I see now that application servers (like jBoss) might grow in the future to do better deadlock detection, to automatically get out of bad scenarios like this one. But in the meantime, we need to put extra logic in our business methods to do proper entity bean access ordering, etc. Thanks, Bryan Georg Rehfeld wrote: 034301c0f097$86c8fa20$[EMAIL PROTECTED]">Hi Bryan, I have an application, in which every client access is done through a Stateful Session bean, which internally manages the Entity beans (Session Facade pattern).Every single method of my session bean is marked as "Requires" a transaction. I realize that this can be a performance hit when it's used unnecessarily. However, I did NOT think that it could lead to deadlock problems! Nowhere do I explicitly create transactions, and no transactions are long-lived (between session bean calls). I THOUGHT (evidently incorrectly) that where concurrent threads need access to the same entity beans, they would be serialized in time. They ARE serialized and thats your problem, serialization basicallymeans 'blocking all others from access, until the first one is done',simplest scenario:timeSession/TX ASession/TX B-T1 access Entity 1T2 access Entity 2T3 try access Entity 2,must wait for TX Bto finishT4 try access Entity 1,must wait for TX Ato finish^^^this deadlocks, each session/Tx waiting for the other to complete. However, instead, I'm getting fairly frequent deadlocks, a total surprise to me. No surprise anymore? Is there a nice way to handle this, or an easy way to debug it? Or is this going to be a nightmare to fix? The only thing to do about that with the current EJB spec is to tryto access ALL deadlock prone beans in the same order (see the 'diningphilosophers problem' in the JAVA tutorial). I.e. you could attemptto access them in increasing Primary Key order from all clients.In the above example the session/TX B then would try to get Entity 1first before accessing Entity 2, waiting there, and session/TX Acould complete.In real world, this ordered access, even with moderately complexapplications, seems near to impossible to implement, especiallyif you allow interactive access to several lock prone resourcesin one (long lived) transaction, where you can't control the order.In such cases there exists a well defined protocol in therelational world, that has proven to work very well and can befollowed by any client. It's based on locking all deadlock proneresources before doing any modification and GIVING UP ALL LOCKS,when one lock can't be obtained, thus allowing other clients toproceed.But the EJB spec is mostly silent about locking, there is norequirement at all to support lock detection (besides timeoutwith distributed TX), thus you can't follow that with EJB.And, so sorry to have to tell you, JBoss has no reliable deadlockdetection yet, neither to detect potential local deadlocksimmediately (as good databases can do) nor the required timeoutdeadlock detection. But there are 2 developers working on thetimeout variant, JBoss will have that soon. Here's to hoping the "Magic of EJB" will again come to my rescue... So sorry again, deadlock really isn't addressed at all in the EJB specs, there isn't any magic, it really sucks.And then I'm sure, the JBoss developer team just is about torecognize the locking/deadlock problem in the context of badperformance in real world apps, maybe they need 2 days or a weekor so to really accept the need, and maybe another week, untilsomeone will be able to jump into that issue, but then they'llshow the world, how a good EJB server plays with that, blamingall others.my best regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Seeking advice on deadlock problem
I have an application, in which every client access is done through a Stateful Session bean, which internally manages the Entity beans (Session Facade pattern). Every single method of my session bean is marked as "Requires" a transaction. I realize that this can be a performance hit when it's used unnecessarily. However, I did NOT think that it could lead to deadlock problems! Nowhere do I explicitly create transactions, and no transactions are long-lived (between session bean calls). I THOUGHT (evidently incorrectly) that where concurrent threads need access to the same entity beans, they would be serialized in time. However, instead, I'm getting fairly frequent deadlocks, a total surprise to me. Is there a nice way to handle this, or an easy way to debug it? Or is this going to be a nightmare to fix? Here's to hoping the "Magic of EJB" will again come to my rescue... Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Whither Java LGPL'd Rules Engines?
I am interested in utilizing a rules engine in my upcoming EJB project. I love jBoss because it works well, it's free, and has a great developer community around it. I'm looking for a rules engine with a similar set of parameters. Does such a thing exist? In particular it needs a strong awareness of and support for J2EE (including EJB and JNDI, and also possibly JSP/Servlets in some capacity). If it doesn't exist, then is it high time to start a new project to develop such a beast? (I would be interested in actively developing). Regards, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] "tuned updates" vs "isModified()"?
The jBoss docs are not very clear with respect to entity beans, "tuned updates", and the optional "isModified" method. If I am using CMP, should I turn on tuned updates, or implement an isModified() method, or both? What about the BMP scenario? Thanks, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Commit option "C" in standardjboss.xml not working?
Because my system (and more often, it's human admins) access the database directly fairly frequently, I am trying to change my jBoss application's commit option from "A" to "C". Rather than implement my own custom container configuration, I'm just trying to change the default setting for all entity beans from "A" to "C". In the conf/tomcat/standardjboss.xml file, I changed the commit option to "C" in both the Standard CMP Entiity Bean as well as the JDK1.2.2 CMP Entity Bean sections (I am using CMP beans). Still, when I test by updating my database directly, and then having my jBoss application display an entity bean's contents, I am not finding the two in-sync. Am I missing something? Thank you, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] How to flush entity bean cache?
Thank you Georg, that is helpful! I have one follow-up question: >From the document you sent me, it looks like I have to set up an entirely custom configuration, just to change the commit option. I'd rather just use the default container configuration and only change the commit option (to "C"). However, if I absolutely must set up a custom configuration, then, how do I know what settings to give it for all the other entires? The document doesn't list the default settings for "Standard CMP EntityBean"; if I knew what those were, then I'd just make a duplicate of it and change the commit options. But as it stands, I don't know how to keep it identical in every other sense. Thank you, Bryan Georg Rehfeld wrote: 013801c0ea0e$af7954e0$fe78a8c0@reathome">Hi Bryan, I am using JBoss 2.2.1 and lots of entity beans. Sometimes I like to go directly to my database (PostgreSQL) and make some changes. But I seem to be unable to do this if jBoss has some beans cached; my changes get ignored, and eventually overwritten (in some cases). You should use commit option B or C in your container configurationinstead of the default A. Migth be commit option D (JBoss specific)would be the right choice for you, but it comes in a future release.Review http://www.jboss.org/documentation/HTML/ch06s08.html forcontainer configurations and the tag .regardsGeorg ___ ___| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] How to flush entity bean cache?
I am using JBoss 2.2.1 and lots of entity beans. Sometimes I like to go directly to my database (PostgreSQL) and make some changes. But I seem to be unable to do this if jBoss has some beans cached; my changes get ignored, and eventually overwritten (in some cases). Without shutting the server down and up again, is there a way I can tell jBoss to flush it's cache? I could flush the cache and then make my direct DB changes immediately, and it should work. Help would be appreciated, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] GOING INSANE: CMP and PostgreSQL
What is the transaction attribute for your entity bean(s)? For entity beans, the transaction attribute can NOT be "supports", "not supported", or "never". If it is one of those, then jBoss will exhibit behavior as you describe (transactions never get committed to the database). I ran into this problem myself a few months back. See this URL for my original thread: http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/msg01164.html Hopefully that's your problem too. If so, we usually get a half-meat, half-cheese, since my daughter is such a picky eater and won't touch anything but a plain cheese pizza. ;) Thanks, Bryan [EMAIL PROTECTED] wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > > >Here's the story: > >CMP Entity beans deploy fine, PostgreSQL connection pool connects fine, Session >beans deploy fine. All works fine EXCEPT!!! > >My bean clients can successfully create, make remote calls to, and modify. >excellent. NO EXCEPTIONS! > >HERE'S THE PROBLEM > >NOTHING IS STORED IN THE DATABASE! > >So, thinking I am just losing my mind, I run the client a second time, this time >doing findByPrimaryKeys on the entity beans. THEY ALL FIND FINE!!! So, I run over >to psql and connect to the database, NOTHING THERE! SAME DATABASE NAME, SAME USER, >SAME PASSWORD, NO DATA! DataSources are correct as far as I can tell, straight outta >the manual. I know it is the right database 'cause it is the only machine, only one >postmaster running, and only one user with one database and it matches EXACTLY in the >jboss.jcml. I even have the '-i' option on in the postmaster startup scripts. > >Hmmm I do a kill jboss. Check the database... nothing there... Startup jboss, >run the findByPrimaryKey again... NO BEAN! do a create()... creates fine...check >pgsql NO DATA! ... do a findByPrimaryKey()... FINDS THE BEAN I CREATED EVEN THOUGH NO >DATA EXISTS IN THE DATABASE! So, I extract all the data from the bean to make sure >it is correct... yep, everything is there, just like I coded. I wonder how it could >get there without being persisted (yes, my ejb-jar.xml is correct, all cmp fields are >there). I would think an exception should be thrown somewhere along the line if I >create a bean and it isn't stored in the database when it should be. > >Stared at the problem for seven hours straight... blew away entire JBoss installation >and started from scratch... twice... same problem. Nothing in documentation or mail >archives suggesting how to actually store data into the database when it isn't >working "in the real world." > > >Ok, can someone please tell me which turns on ACTUAL >DATABASE WRITES AND NOT JUST A TEASE! > >There HAS TO BE something I am missing. > >I'll buy the first person who answers this correctly a pizza. I'm not kidding. > >- - - - >[EMAIL PROTECTED] >F46A 36F7 3E52 132A 72C5 8628 784A 0877 4D98 27BE >http://www.sicore.org/publicKeys/damon.txt >-BEGIN PGP SIGNATURE- >Version: GnuPG v1.0.4 (GNU/Linux) >Comment: To iterate is human. Recurse, divine. > >iEYEARECAAYFAjsUkP0ACgkQeEoId02YJ76BZwCgjTgNQxIzVzZVvdzi41hjIttg >wGYAoOozwj1MrzuXVjBO05OWlbDJeXGt >=dwqi >-END PGP SIGNATURE- > > >___ >JBoss-user mailing list >[EMAIL PROTECTED] >http://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Tomcat+jBoss EAR with Virtual Hosting?
Hi, I'm using Tomcat+jBoss and deploying an EAR file. Everything seems ok, except I'm confused about how to turn this into a Tomcat "virtual host" instead of just a plain "context". There doesn't appear to be a way to specify virtual hosting parameters in application.xml. Is this possible? Thanks, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Client-demarcated transaction from jBoss+Tomcat?
I am moving a Servlet application from JOnAS to jBoss. I am in final testing now and am discovering that jBoss does not really support client-demarcated transactions (because there is no distributed transaction manager). However, in my case, my "client" (which must manage transactions) is in my Servlet, and with Tomcat+jBoss, they are part of the same VM. So in my environment, is it possible for me to do client-demarcated transactions after all? If so, how can I obtain a UserTransaction from my servlet code? Thanks (And please, don't anyone tell me to implement a session facade instead, I've got too much code to migrate in too short a time!) Regards, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] jBoss+Tomcat (default config) creates 53 threads?
I'm using jBoss+Tomcat, latest version, on RedHat Linux 6.2. When I start jBoss+Tomcat using out-of-the-box configuration, the thing is creating 53 threads. This of course makes for terrible clutter of my "ps ax" display, and also makes me wonder whether or not there is some kind of worker thread queue whose default settings are overkill. For example, Apache out-of-the-box keeps 5-10 worker processes "on standby", which I reduce to 3 for manageability (I'm running some relatively low-use sites). Can I do anything similar with jBoss+Tomcat? Thanks, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Stateful session beans, concurrency, and blocking?
That seems crystal clear to me. Without the spec changing, it seems like the burden is on me to syncronize access to the session bean reference. Off the record this seems kind of silly, it should really be a deployment option whether to reject, or else syncronize, concurrent access to the bean. Either way you achieve the primary design goal, which is to prevent concurrent access. Bryan Scott M Stark wrote: > It says must as I read it. It is putting the burdon of correct usage on the client > rather than the container. > 6.11.6 Non-reentrant instances > > The container must ensure that only one thread can be executing an instance at any >time. If a client > > request arrives for an instance while the instance is executing another request, the >container must throw > > the java.rmi.RemoteException to the second request. > > Note that a session object is intended to support only a single client. Therefore, >it would be an > > application error if two clients attempted to invoke the same session object. > > > - Original Message - > From: Bryan Field-Elliot > To: [EMAIL PROTECTED] > Sent: Thursday, April 05, 2001 11:27 AM > Subject: Re: [JBoss-user] Stateful session beans, concurrency, and blocking? > > > Regarding the EJB spec -- > > In the scenario in which their is an attempt at concurrency by a Stateful Session >Bean client, does the spec _specifically_ say, > "throw an exception"? Or, does it say, "don't allow it" (but leave a gray area >whereby a container might choose to block caller #2 > until caller #1 is finished)? Either scenario seems fine with me, it seems like it >should be up to the developer to choose a > strategy, but (as comic Dennis Miller says), "that's just my opinion and I could be >wrong". > > Bryan > > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Stateful session beans, concurrency, and blocking?
Regarding the EJB spec -- In the scenario in which their is an attempt at concurrency by a Stateful Session Bean client, does the spec _specifically_ say, "throw an exception"? Or, does it say, "don't allow it" (but leave a gray area whereby a container might choose to block caller #2 until caller #1 is finished)? Either scenario seems fine with me, it seems like it should be up to the developer to choose a strategy, but (as comic Dennis Miller says), "that's just my opinion and I could be wrong". Bryan danch wrote: [EMAIL PROTECTED]">Ouch! Frames Bad!At worst, you could grab the stateful session instance interceptor andmodify it so that you can have your own, non-compliant stack. Bryan Field-Elliot wrote: I am developing a web application, in which the web tier is creating aStateful Session bean for each user, and invoking methods on it for allbusiness logic.Problem is, part of my web application requires framesets, and eachframe pane needs to invoke methods on the session bean. When two framessimultaneously load, and their corresponding JSP pages simultaneouslytry to invoke methods on the same session bean, one of them fails with a"TRANSACTIONS ROLLED BACK EXCEPTION", having to do with being calledfrom the wrong transaction context.I know that this is the correct behavior per the EJB spec, but what I amwondering is, can I configure jBoss to block the second call until thefirst call is done, rather than instantly throw an exception?This would instantly solve my problem, without writing a ton of extracode in my web tier to do syncronization etc.Thanks in advance,Bryan___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized.If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.___JBoss-user mailing list[EMAIL PROTECTED]http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Stateful session beans, concurrency, and blocking?
I am developing a web application, in which the web tier is creating a Stateful Session bean for each user, and invoking methods on it for all business logic. Problem is, part of my web application requires framesets, and each frame pane needs to invoke methods on the session bean. When two frames simultaneously load, and their corresponding JSP pages simultaneously try to invoke methods on the same session bean, one of them fails with a "TRANSACTIONS ROLLED BACK EXCEPTION", having to do with being called from the wrong transaction context. I know that this is the correct behavior per the EJB spec, but what I am wondering is, can I configure jBoss to block the second call until the first call is done, rather than instantly throw an exception? This would instantly solve my problem, without writing a ton of extra code in my web tier to do syncronization etc. Thanks in advance, Bryan ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Verifier Error Messages
I use Together CC also. I believe this problem is that the method signatures in the remote interface (which Together generated) are throwing EJBException, when they shouldn't. I always have to delete that exception from the throws clause of my remote interface after adding a new business method via Together. Together's EJB support is good enough to hook you in and then leave you stuck and screwed, IMHO. Throwing of EJBException is one example of this (non-spec-compliant). To be fair, jBoss's verifier error message in this scenario is equally unhelpful. Bryan [EMAIL PROTECTED] wrote: > Hi - > > I have the following error message from jBoss 2.1: > > > [Container factory] > Deploying:file:/D:/jboss-tomcat-2.1-beta/jboss-2.1/tmp/deploy/Default/ejb_mats.ear > > [Verifier] Verifying > file:/D:/jboss-tomcat-2.1-beta/jboss-2.1/tmp/deploy/Default/ejb_mats.ear/ejb1001.jar > > [Verifier] > Bean : EquipmentRequirementBean > Method : public abstract EquipmentRequirement create() throws CreateException, > RemoteException, SQLException > Section: 9.2.8 > Warning: The method return values in the home interface must be of valid types > for RMI/IIOP. > > [Verifier] > Bean : EquipmentRequirementBean > Method : public abstract EquipmentRequirement > findByPrimaryKey(EquipmentRequirementPK) throws FinderException, RemoteException > Section: 9.2.8 > Warning: The method return values in the home interface must be of valid types > for RMI/IIOP. > > > I used Together Control Center 4.2 to create my entity beans and have this > message all over the place, for all my entity beans... > > Any ideas what it means? Is it specific to EJB 1.1 versus EJB 2.0? > > Any help would be great. > > Thanks! > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
