Re: [JBoss-user] JBoss Entity Bean Transactions
Hi Luke, > Would it be true to say that JBoss implements option A? I am > certainly seeing this type of behaviour with my session wrapped > entity beans, i.e. no ejbLoad() called for new Transactions after > the initial find/ejbActivate combo. ... Yes, the default configuration for JBoss is commit option A. > ... Is it possible to configure JBoss to use one of the other > options mentioned in the spec? I.e. I basically need ejbLoad to > be called on the entity beans afresh in each transaction. Yes, have a look into the docs at http://www.jboss.org/documentation/HTML/ch06s08.html and search for . JBoss supports all options from the spec (A, B and C) plus another JBoss special one. There are rumors, that option C does not work correctly (it's told, that the entity bean is not reloaded at start of a new transaction). I can't believe that, but I havn't tested that myself. If you plan to use commit option C you must be sure to declare your methods as transaction required INCLUDING the finders! But just in case I repeat what others did to ensure reloading: they have set and in the to exactly 1 (same document as above). regards Georg ___ ___ | + | |__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
Re: More Re: [JBoss-user] When do entity beans commit?
Dear Bryan, > 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=] This clearly indicates access to an instance INSIDE a transaction that already is associated to another TX. Interesting would be to know if only staffBean with PK 73 is logged, or if other beans are involved/logged, and then which Transaction Global Id is shown there. In a true deadlock scenario you should see one instance logged with (in your case) 73 + app-web1//188 and at least one other with some other PK and Global Id (say 42 + app-web1//4711), in your case I expect both of type staffBean, but in complexer scenarios it could be of some other type. And the true deadlock case could even involve more beans cyclic waiting for each other. If you only see 73 + app-web1//188 LOCKING-WAITING it's more likely, that the instance is participating in a lengthy processing, so that TX app-web1//188 finally gives up, although now true deadlock condition exists. But having said all this, you told us, that the sessions method is 'Never' and the entity methods called are 'Supports', so you are right, there should be no transaction at all. And I assume, that, while your tests were running no intentional transactional methods were invoked? The last idea I can come up with is: might be you have a typo in your 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 at deployment time. If this even isn't the case, I would report this as a possible bug at SourceForge, as nobody else came into this thread of discussion to help us. Best you would provide more complete server.log and your relevant deployment descriptor parts and code samples (i.e. for others to have a true look at case and names of methods etc.) Ah, and a final note: the code around the LOCKING-WAITING and the Exception you receive was just reworked to solve some other problem. The modifying author (Bill Burke) said, this only is a partial attempt at the LOCKING-WAITING (he was focused on the other problem, which he solved) issue, but the JBoss founder Marc Fleury is just about to rework that code even more. This modification(s) do nothing about the fact, that you see transactional behaviour, where it shouldn't be (IMHO), but if the above guess doesn't hold, you still may want to try the new version out. It's only checked into CVS, so you had to compile JBoss yourself for a test. > 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? As far as I understand the code version you are executing (2.2.1 or 2.2.2 I assume, did you tell us?) there could be deadlock with non-reentrant beans, at least when they actually do a callback (which would require reentrant to be enabled), but this would be logged differently, so in your case it doesn't seem to be the reason. 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 forever This is due to a bug (I think) in JBoss in an attempt to be more wise than the EJB Spec, which requires an EJBException to be thrown when B calls back A via mA2 while A still is not finished with mA1 and the bean A isn't reentrant. JBoss instead would go into 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 code around, 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 do a test case now. If I turn out to be right, I SHOULD report that as a bug (that code in EntityInstanceInterceptor is really too tricky to fiddle with, when unexperienced)! best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: Bryan, could you please switch to ASCII instead of HTML, it's preferred/required on this list and by me too. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] manual
Hi, note, I'm not complaining about bad JBoss docs, I find them brief and enhancable but covering most important things yet, but Scott M Stark said: > 3. Read the ultimate docs(the source) ... I don't agree with this, the ultimate doc is the doc! The importance of documentation was addressed by SUN with the JavaDoc tool for low level docs, but the rule applies to high level docs too. The 'ultimate docs are the docs' rule especially is true for Interfaces, which most often is the thing users program against while getting some or the other implementation at runtime which might differ greatly while behaving all as specified for the interface (hopefully). This simply, because for an IF there is often no or no single impl to look at. One heavy pitfall of the 'ultimate doc is the source' rule is code containing a bug. You never should assume that the existing code is to be interpreted as the doc, which would declare the bug to be the intended behaviour. But without docs, how could the bug ever discovered (except for really obvious ones)? By a human, often the author himself, knowing or guessing the INTENTION of the code and comparing the intention <=> documentation to the existing implementation and discovering, that they differ. Another example: I once had a *.properties file with duplicate keys (by intention, don't tell you the whole story here) and wanted to know how java.util.Properties would deal with that. The docs for Properties.load() are lengthy about the expected format, but say nothing about dups. So I looked up the impl and found, that the last duplicate key/value pair in the file was the final result. Should I now use this knowledge and rely on that behaviour? Never! Because the impl at any time can change without notice, the behaviour is undefined, so don't use it. Else you would introduce very subtle and difficult to find bugs whit the next JDK or with some subclass of Properties, that does other things and so on. Having said that back to work. And please know, Scott has given sooo much source AND documentation to JBoss and advice to users on this list that nobody of us avarage readers here ever can keep up with him. Very respectful Georg ___ ___ | + | |__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
Re: [JBoss-user] LOCKING-WAITING
Hi, ivanhoe Abrahams wrote: > Could anyone point me in the right direction when it comes to solving > the LOCKING-WAITING problem > It hangs my client/keeps the server so busy that everything slows down > to a snail's pace. In the current CVS version of JBoss is a partial fix for that and some developers are just working on the final fix. I didn't try the partial fix yet, if you do, it would be nice to report back to the list (or at least to me) how it changes behaviour. > Ps. a good explanation of the problem (a deadlock I assume) would be > interesting to chew on. Essentially quoting from one of my previous mails: - begin quote - simplest deadlock scenario: timeSession/TX ASession/TX B - T1 access Entity 1 T2 access Entity 2 T3 try access Entity 2, must wait for TX B to finish T4 try access Entity 1, must wait for TX A to finish ^^^ this deadlocks, each session/Tx waiting for the other to complete. > 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 try to access ALL deadlock prone beans in the same order (see the 'dining philosophers problem' in the JAVA tutorial). I.e. you could attempt to access them in increasing Primary Key order from all clients. In the above example the session/TX B then would try to get Entity 1 first before accessing Entity 2, waiting there, and session/TX A could complete. In real world, this ordered access, even with moderately complex applications, seems near to impossible to implement, especially if you allow interactive access to several lock prone resources in one (long lived) transaction, where you can't control the order. In such cases there exists a well defined protocol in the relational world, that has proven to work very well and can be followed by any client. It's based on locking all deadlock prone resources before doing any modification and GIVING UP ALL LOCKS, when one lock can't be obtained, thus allowing other clients to proceed. But the EJB spec is mostly silent about locking, there is no requirement at all to support lock detection (besides timeout with distributed TX), thus you can't follow that with EJB. - end quote - ___ ___ | + | |__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
Re: [JBoss-user] I'm I tripping? Or does JBoss 2.2.1 call ejbStore() on my ejb way too often??
Hi Robert, Robert Finneran wrote: > The JBoss container seems to call ejbStore() on my BMP-style > entity bean very often. > This results in multiple unecessary UPDATE's to my base table. > > When does JBoss decide it should call ejbStore()? It stores at the end of every transaction and is required to do so by the EJB specification. RTFM http://www.jboss.org/documentation/HTML/ch06s08.html under the tag. Besides, interpret F as you want, but I meant FINE! regards Georg ___ ___ | + | |__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
Re: [JBoss-user] How to use JAWS ?!
Hi, Lau Chet Hong wrote: > 1. Do I start JAWS by running 'java -jar ejx.jar' ? No, with that command line you start a GUI tool that is able to edit some XML files related to J2EE/JBoss bean development, amoung them also the jaws.xml file, that contains the CONFIGURATION for your CMP beans. JAWS is integrated into JBoss and you haven't to start it separately, it does it's job silently as the JBoss CMP engine, looking at standard-jaws.xml for defaults and your deployed jaws.xml files for specifics. It isn't possible to start JAWS independently from JBoss. > 2. After starting JAWS, can I open an existing ejb-jar.xml or >jboss.xml or jaws.xml? I keep getting error box saying 'Could >not load file:null' when I try to open the above .xml files, even >the sample source code I downloaded are giving the same problem. > > 3. If I want to create a new .xml file from JAWS. All I see are >some dialogs which doesn't allow me to type in much things. Replace 'JAWS' with 'EJX' and I confirm to have experienced this same behaviour. EJX for sure isn't user friendly at all, when it has problems! (And again, it is UNFRIENDLY SHOUTING by intention). Some day, and I'm really sorry beeing unable to tell you the reason, EJX suddenly worked for me, opening files nicely that I was unable to open before and creating new *.xml files, which didn't work before. Sorry again, but the behaviour was almost as if the coder of EJX had built in some counter: "let that stupid users hit me 10 times and then I'll start to be usefull". I promise to look into that code and at least come up with more helpfull error messages. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] (no subject)
Dear Pete, Pete Bastawros, Technical Director, MOYES & CO., INC. wrote: > In dire straits. Not much experience with Perl. I would like to > read record IDs either in text (below) or a variable from ASP > into a Perl script. Can anyone help me? > > ASP query result looks as so: > > 122736122733122740122742122743122770 > > (with html tags before) cut off your HTML tags somehow until the string shown above is left in some variable, (i.e. $id_strings), then simply do: @ids = split(/\/, $id_strings); and you have a list (array) of all your ids in @ids stripped from the and ready to be processed. Besides, you are on the wrong list, the 'jboss' mailing list is not meant to help out 'bosses' (or managers or directors) with their problems, whatever they are. But then you might find many 'boss' level developers and project managers around here, so you are welcome to check back and read one or the other. And it might be better for you and your company to switch from ASP to JSP and EJB, especially JBoss bundled with TomCat or Jetty, have a look at http://www.jboss.org/ and direct your 'staff' to it, maybe, they already told you about and you didn't know it? have a nice day Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: If you continue to use Perl (not a bad decision) you really should consider reading 'Programming Perl' completely, it's ally fun! Authors: Larry Wall, Tom Christianson and Randal L. Schwartz O'Reilly & Associates, Inc. ISBN: 1-56592-149-6 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: More Re: [JBoss-user] When do entity beans commit?
Hello Bryan, > 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, Difficult to guess from what you tell us. Do you use select for update, so that the DB causes deadlocks? Are there other resources you try to access concurrenty? Is it possible that some bean does lengthy operations (or hangs) while others try to access 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 the TransactionRolledbackException in the server.log that might indicate whats going on? > Your state charts of I's and dashes are awesome! Actually I tried to draw Sequence Diagrams, I find them helpful sometimes. > 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. I think, you do it, as I would have done it, as long as you are aware of the dirty/invalid data status and do not try to modify anything based on it. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] When do entity beans commit?
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 return from the Entities method set to Requires. I crosschecked the code in 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->I I I | TX.commit | I I | | I I | TX.begin | I I-->I I I | TX.commit | I I TX.begin | | I->I | I I TX.commit | | Thus you should see no deadlock caused. regards Georg ___ ___ | + | |__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 PM Subject: [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] Re: Primary Key Error? (was Re: OutOfMemoryError)
Hi danch, this is an excellent description, that should make it into the JBoss docs! regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 9:26 AM Subject: Re: [JBoss-user] Re: Primary Key Error? (was Re: OutOfMemoryError) > Nicolai P Guba wrote: > > > Simple question (I hope): > > > > If I'd like to use CMP for a project. mySQL supports auto-generating > > the primary key for an inserted row (AUTO_INCREMENT). Is this feature > > supported by jboss? > > > > If not, what strategy would you recommend for handling primary keys > > (never done it any other way but to rely upon the database to generate > > the value). > > Ah! I think I may have tried answering this, but had problems with > outbound mail from work. > > auto_increment is not supported by JBoss at this time - there are way > too many different syntaxes, and in some databases it isn't possible for > the container to get the key value back, which is a Bad Thing. > > I would reccommend that you use a database sequence facility, if > available (I'm not a mySQL user). You can lookup your datasource and > make your call to get the key value just as you would in a BMP bean > (don't do the insert!, just get the key value and assign it to your key > field and return it) > > You might want to take a further step and put the call to the sequence > into a stateless session bean's method and mark that method as > RequiresNew transaction. This way you'll release any locks on the > sequence quickly (though you might have unused numbers in your PK - if > that's a problem you're probably doing something unwise) > > If mySQL doesn't have standalone sequences, you can construct a table > with a key-name column and a key-value column, then get the values out > of that by calling another bean with RequiresNew transactions. The > RequiresNew is very important here if you expect to require any > conncurrent inserts. > > -danch ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] jBoss 2.0 Final: Has anybody the original zip-file??
Hi Daniel, > for some tests I need the original zip-file of jBoss 2.0 FINAL. > > Have anybody of you have that file? > If you have it, please send it to me or send me a link where I can get it. > The link on jboss.org is dead! I have it bundled with tomcat. But before sending 8.7 MB around multiple times to you, shall I send it really? regards Georg ___ ___ | + | |__ 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
Re: [JBoss-user] Seeking advice on deadlock problem
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 basically means 'blocking all others from access, until the first one is done', simplest scenario: timeSession/TX ASession/TX B - T1 access Entity 1 T2 access Entity 2 T3 try access Entity 2, must wait for TX B to finish T4 try access Entity 1, must wait for TX A to 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 try to access ALL deadlock prone beans in the same order (see the 'dining philosophers problem' in the JAVA tutorial). I.e. you could attempt to access them in increasing Primary Key order from all clients. In the above example the session/TX B then would try to get Entity 1 first before accessing Entity 2, waiting there, and session/TX A could complete. In real world, this ordered access, even with moderately complex applications, seems near to impossible to implement, especially if you allow interactive access to several lock prone resources in one (long lived) transaction, where you can't control the order. In such cases there exists a well defined protocol in the relational world, that has proven to work very well and can be followed by any client. It's based on locking all deadlock prone resources before doing any modification and GIVING UP ALL LOCKS, when one lock can't be obtained, thus allowing other clients to proceed. But the EJB spec is mostly silent about locking, there is no requirement at all to support lock detection (besides timeout with distributed TX), thus you can't follow that with EJB. And, so sorry to have to tell you, JBoss has no reliable deadlock detection yet, neither to detect potential local deadlocks immediately (as good databases can do) nor the required timeout deadlock detection. But there are 2 developers working on the timeout 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 to recognize the locking/deadlock problem in the context of bad performance in real world apps, maybe they need 2 days or a week or so to really accept the need, and maybe another week, until someone will be able to jump into that issue, but then they'll show the world, how a good EJB server plays with that, blaming all others. my best regards Georg ___ ___ | + | |__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
Re: [JBoss-user] ./conf directory location
Hi Julian, > The point (IMHO) is that whilst mulitple users should > be able to share a JBoss installation, they will want > to run it with their own configurations. Otherwise he > would have stuck the whole lot in his home dir. > > Q1. Can I e.g. run multiple JBoss instances from the > same installation via different configs (provided of > course they have different DBs etc and don't blat all > over each other). This should work, be carefully to change all communication ports likewise (see docs, there are several of them) and have some central person/script manage all those unique port numbers and resources, to avoid strange testing behaviour. > Q2 How ? > > I had a quick look at the code. The decision about > where to find the conf dir is made in org.jboss.Main > around line 135. You call e.g. ./run.sh jetty and the > code will figure the conf dir to be ../conf/jetty > (this is relative to the bin dir). > > I tried copying the jetty dir to /tmp/foo and trying > various incantations such as ./run.sh > ../../../../../../tmp/jetty - but no dice. Maybe I > missed something. Your change will not work, as you have to have the conf directoy in your classpath (in jboss.jcml). But I would suggest just the other way round: keep the different user configs in $JBOSS_HOME/conf/, change the permissions, so that JBoss can read, but only the user can write (except for jboss-auto.jcml, which must be writable by JBoss) and have a link from each users home to his config directoy. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] Differences in ejb methods called for BMP beans
Hi Mark, > Orion 2nd request - returns 1 -row > > MVSBase() > MVSBean() > setEntityContext() > ejbFindByServerName() > Begin Time: 2001.06.08 at 09:00:13.440 AM EDT > End Time: 2001.06.08 at 09:00:13.590 AM EDT > ejbActivate() > ejbLoad() > ejbStore() > JBoss 2nd request - returns 1 -row > > [MVS_BMP] ejbFindByServerName() > [MVS_BMP] Begin Time: 2001.06.08 at 09:02:54.692 AM EDT > [MVS_BMP] End Time: 2001.06.08 at 09:02:54.832 AM EDT looks to me, as if you only do the finder, but don't access the bean with some getter/setter. If so, I'm not sure, why Orion does all the other calls, may be, they preload the bean instances when the finder executes, but then, why ejbStore()? JBoss does not preload the beans, someone is working on caching the complete bean data with JBoss CMP at finder time, but I think, this will not instantiate the beans, but cache the raw data elsewhere. The JBoss way is more effecient, don't you think so? And Orion seems to instantiate the beans on demand, as can be seen from the constructor msgs, whereas JBoss pools unused bean instances, again a better solution. But, if you actually DID execute some business method on the found beans, something must be wrong with your logging. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] RE: JBoss-user digest, Vol 1 #711 - 10 msgs
Dear mohan, > Can any one clear the following my doubt: > where I have to keep my java bean to use with my jsp or servlet, please? Sorry, if you find this impolite, but did you recognize, that you sent 833 lines of irrelevant stuff to all of us, just to ask a two line question?!! That's disrespectful. Please either learn how to use your mailer or simply use it i.e. by cutting off unneccessary tails and giving a reasonable subject line. And besides, you didn't answer to anything, what made you think you should reply to some message, especially a digest? Just to save you some few klicks or keystrokes to get the right mail address allows you to flood us with junk? Never! So, I'm calming down again, back to your question, I think you at least should have a brief look at the JBoss docs located at http://www.jboss.org/documentation/HTML/index.html, skip, what seems to be too complicated at the first glance, and look out for the magic words JAR, WAR, EAR and JNDI lookup. bye Georg ___ ___ | + | |__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
Re: [JBoss-user] Version control
Hi Paula, > To try to clarfiy, my data will be stored in a database..as yet I don't know > which one. I guess I was trying to figure out if given multiple clients > manipulating data via EJBs, is there anyway to have one of these clients > with administrator 'rights' who can rollback changes made by any of the > others, at anytime. Those changes could have happened two days ago > potentially. I was thinking along the lines of sourcesafe's implementation. JBoss can't help and it isn't it's responsibility at all IMHO. What comes to mind would be a database with some history functionality. As far as I know Postgres had/has such a feature, but seemed to be a little bit buggy and wasn't used widely, so they have taken it out or will so in the future. And even with that it could be difficult to take out single transactions without violating consistency of following transactions. As a sample, consider some salesman increasing his sales erroneously and committing. Next day another transaction gives him commission on sales effected. Just another transaction books taxes based on the sales under error. And still other transactions do bookkeeping, reporting to the management and so on. Now the faulty sales increment will be taken out by an admin, how do you think all the following transactions, that based on the committed, but wrong sales value, should be corrected? regards Georg ___ ___ | + | |__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
Re: [JBoss-user] question about bug: LOCKING-WAITING (TRANSACTION) ...
Dear Gianluca, sorry for the delay, I was busy. > In the jboss mailinglist archive I found the mail Georg Rehfeld mail (08 May > 2001) with subject: Transaction blocks forever, LOCKING-WAITING > > > > ... > > > I can access several beans in the first > > > place, but after a short while I again get a block in the JNDI > > > lookup() method followed by a transaction timeout message but > > > with no exception raised. The entity bean remains associated > > > with the transaction for ever; the next access to it again > > > produces the millions of 'LOCKING-WAITING (TRANSACTION)' > > > messages and only a server shutdown helps. ... > > I read the Bordet Simone reply that this is a bug and it has to add on the > SourceForge site... In my case the problem was really a JNDI lookup. Another user (Max Du Prel) had a similar problem and could solve it, in his case someone broke his network configuration, see his bug report at https://sourceforge.net/tracker/index.php?func=detail&aid=421293&group_id=22 866&atid=376685. Until today I believed, that the JNDI lookup on my machine was not related to network config problems, so I did work around the problem by implementing a JNDIHelper class, that does the lookup in a seperate thread, kills that thread when not responding in time, does the lookup again and caches the result for later use. If you would be interested, I can send the code. But today I was able to resolve another issue (could not start JBoss CVS built from source, problem reportet, I'll report the solution separately) and I think (but havn't tested yet) this could be the reason for the lookup problem too: My ISDN card (AVM Fritz! card) had installed a 2nd (pseudo) network device. Today I recognized, that pinging myself (via my official name, not localhost) resolved to the ISDN pseudo interface instead of the primary interface. I disabled that ISDN interface and, voila, JBoss CVS started up cleanly. Please note, that all obvious network settings including winnt/system32/drivers/etc/hosts were perfectly ok, but W2K did the resolving wrong. And, except with JBoss, all my networking seemed to be unproblematic. What I think is going on is, that resolving names sometimes gets one interface and sometimes the other so that reliable communication can't be done. So, please, triple check, that your W2K really, really, really behaves as you expect it to behave and as you think you have it configured. > I have the same (or similar) problem: > > I'm using CMP entitys and after a while I'm using the entitys by a session I get > a lot of this log message (millions): > > [Scenario] LOCKING-WAITING (TRANSACTION) for id 1 ctx.hash 8040172 > tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=byrne//801, BranchQual=] This problem [the repeating messages and the tight loop stressing CPU] just was heavily addressed yesterday at the jboss-dev mailing list and it seems that 2 developers decided to cooperate on a solution for it, Bill Burke, who said he would do the initial coding (in context of just another problem he has detected) and Dan Christopherson, reviewing the change; thanks to both of them. > and some time between the message log before in the log file I found: > > [ScenarioShp] Transaction XidImpl [FormatId=257, GlobalId=byrne//799, > BranchQual=] timed out. status=STATUS_ACTIVE > ... > [ScenarioShp] Transaction XidImpl [FormatId=257, GlobalId=byrne//801, > BranchQual=] timed out. status=STATUS_ACTIVE > ... > [ScenarioShp] Transaction XidImpl [FormatId=257, GlobalId=byrne//803, > BranchQual=] timed out. status=STATUS_ACTIVE > ... This looks to me, as if 3 (or more?) beans are deadlocked, because of the 3 different GlobalID's 799, 801 and 803, this should be reflected also in the LOCKING-WAITING messages. Bill and Dan for sure will solve the deadlock problem (via timeout) as this issue was discussed yesterday too. > Another similar problem I think is the following: > > I have 2 application deployed in jboss: > - application A: datasource DA, database DBA > - application B: datasource DB, database DBA > > In both applications I'm using some entity CMP and a session (stateless). > > Application B in a session bean (stateless) uses some entity of application A, > because need to make a copy in the application B. So it get information from > application A by entity, create new entity in the application B and make a copy. > After a while my application don't give me any answer, but I didn't get any > exception (like a loop). > After some time in the log file I get the message: > > [Emergenza] Transaction XidImpl [FormatId=257, GlobalId=byrne//441, BranchQual=] > timed out. status=STATUS_ACTIVE > > but the application still blocked and I have to
Re: [JBoss-user] Re: [JBoss-dev] Serious Bug? EntityBean out of synch with database.
Hi awc (?), > May be this is your problem. I had dataHolder bulk accessor object that move out > data in one shot. If you do have one like that, set it to null in ejbPassivate(). > > Otherwise if you call entity bean 1,2,3 and recall 3,2,1 you will get the correct > results. > If you recall 2,1,3 you will get 3,2,1. Could you please explain why this happens? I'm just not aware if one should consider it a bug or a feature. Thanks Georg ___ ___ | + | |__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
Re: [JBoss-user] Using a new JDBC datasource
Hi Justin, > javax.ejb.EJBException > org.jboss.ejb.plugins.BMPPersistenceManager.storeEntity >(BMPPersistenceManager.java:352) > org.jboss.ejb.plugins.EntitySynchronizationInterceptor >$InstanceSynchronization.beforeCompletion >(EntitySynchroniztionInterceptor.java:370) The code at BMPPersistenceManager.java:352 calls your beans ejbStore() method, catches a RuntimeException thrown from it and repackages it inside an EJBException, so the real cause can't be seen without retrieving it from the EJBException with getCausedByException(). But in your stacktrace there is no good place for you to catch the EJBException and retrieve the real cause (all methods are container internal). Maybe it would help to put your complete ejbStore() methods code into a try/catch block where you catch Exception, print a stack trace and rethrow the Exception, so you can see what's really going wrong? If you wonder at ejbStore() beeing called after a getter method please read comments in http://www.jboss.org/documentation/HTML/ch06s08.html under the label . regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: I believe, the container should have handling for extracting the real cause from an EJBException somewhere. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Using a new JDBC datasource
Hi Justin, > id : XidImpl [FormatId=257, GlobalId=justin//0, BranchQual=1] > twoPhase : true > active : false > current : XidImpl [FormatId=257, GlobalId=justin//0, BranchQual=1] > Con transaction isolation level : 1 > Con is closed : false > Con is read only : false > Con is auto commit : true - > Throw XA_HEURCOM exception The autocommit is the problem. The connection is definitely set to autocommit(false) in org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl.getXAConnection(). The HeuristicCommit Exception is thrown by minerva, because it can't control the transaction anymore, when the underlying driver/connection commits automatically. Might be, your driver accepts setAutoCommit(false) without throwing an exception, but silently ignores it and remains in autocommit mode? Is Cobol transactional at all? regards Georg ___ ___ | + | |__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
Re: [JBoss-user] Commit option "C" in standardjboss.xml not working?
Hi Brian, > 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). Should work. > 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. this sounds VERY strange, are you sure, that you execute your methods inside a transaction (i.e. the transaction attributes set to Required, RequiresNew or Mandatory). If so, could you please put debug output in the ejbLoad() and ejbStore() and some test methods of a test bean and verify, that ejbLoad() really is called before every business method as given in the following diagram: All methods declared as TX 'Required'! container/ entity entity bean clientsession bean remote IF impl DB ---------- | rw_val() | | | | I-->I read_val() | | | I I-->I | get state | I I I ejbLoad() I<--I I I I->I | I I I read_val() I | I I I->I | I I write_val() I I | I I-->I I | I I I write_val() I | I I I->I | I I I ejbStore() I | I I I->I put state | I I I I-->I | | | | | | inc_val() | | | I-->I | get state | I I ejbLoad() I<--I I I->I | I I inc_val() I | I I->I | I I ejbStore() I | I I->I put state | I I I-->I | | | | Setting the option to true in (standard)jaws.xml will show the get_state/put_state SQL. Another thing to note is: without true XA compliant JDBC drivers there will be no DB locks set when reading data from the DB, thus another app may change the DB in the time between get_state and put_state, resulting in synch errors. You might want to set the option in jaws.xml or standardjaws.xml to true, see http://www.jboss.org/documentation/HTML/ch05s03.html. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] minerva connection pools
Hi Doug, > I need to provide fail over for my database. > ... replica ... only contains report tables. I don't think, minerva (jbosspool) will give you a connection to a database, that is down (didn't check the code, but seems to be obvious). In your case, where the replica is readonly (and not might have all tables/columns of the original) it seems, you are better off, when minerva/jbosspool throws the exception before you attempt to do updates. This way you can have an 'intelligent' getConnection() implementation (in every bean, or a superclass, or a collaborator) that cycles through available DB's and sets a flag in the bean if updates are allowed or not, easily to be recognized in ejbStore() (and ejbLoad/Create/Remove(), if neccessary). Hmmm, this looks like 'design by Exception', generally a bad design, but I don't know of a way to ask minerva/jbosspool beforehand, so I think, it's ok this time. Oops, this advice only holds for BMP, no idea how to proceed for CMP. sorry Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: exeptional quoting the whole original message PS2: cutting tails is fun - Original Message - From: "Ferguson, Doug" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 02, 2001 10:42 PM Subject: [JBoss-user] minerva connection pools > Hi, > > I need to provide fail over for my database. > We have a replica of our database that doesn't contain stored procedures or > and of the mechanisms for data loading. > It only contains report tables. > > The idea is that if the main database goes down, even for maintenece we can > fail over to the mini DB. > > I was planning on implementing a try/catch on the connection to the > connection pool and wasn't sure if minerva > would just spit out a connection even if there were issues with the > database. If that is the case then I won't see > the SQLException until I actually do something with the connection which is > more of a bitch to deal with. > > Any suggestions on how to deal with this sort of issue? > > Thanks, > d. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] How to flush entity bean cache?
Hi Bryan, > 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"). If all your data is accessed from other applications it would be best to change the commit options for all container configurations in standardjboss.xml and you are done. If only the data for a few beans is concurrently accessed from other apps, it would be better to have custom additional configurations for them in jboss.xml (which is put into the jar where the beans live). Elsewhere the docs say, that jboss.xml is interpreted as a 'diff' to standardjboss.xml, so that you may easily still use a standard configuration, but provide the other commit option in jboss.xml as in this example: - jboss.xml Standard CMP EntityBean B -- end - > 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. Simply copy over a complete container configuration from standardjboss.xml to your jboss.xml, rename it as you want and change any setting as appropriate. Don't forget to associate your bean(s) with the custom configuration(s). Reread the given doc reference from the beginning, it's all there. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] How to flush entity bean cache?
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 configuration instead 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 for container configurations and the tag . regards Georg ___ ___ | + | |__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
Re: [JBoss-user] manual build fails
Hi Tahir, > Just tried to checkout/build manual module and it fails > with the following exception. (target printablehtml) ... > anybody tried this bofore with any luck? Just tried it on my W2K box with the latest CVS version, works OK for me, except that I get repeated: | Call to extension function failed: com.nwalsh.xalan.Table messages, but the generated HTML looks good. regards Georg ___ ___ | + | |__ 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
Re: [JBoss-user] JBoss Manual
Hi Simon, > I am new to using JBoss, and was just wondering if there is any > way I can download the JBoss documentation rather than having to > view it online (using the "Manual - online HTML version" tab on > the JBoss Documentation page). Simply follow the instructions given in: http://www.jboss.org/business/doco.html under "Manual - CVS module for contributors" regards Georg ___ ___ | + | |__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
Re: [JBoss-user] " [mysql] no transcation right now", what does it mean?
Hi wizard, > I try to use a new version of mysql that supports transaction . > I can do some transaction operation on BDB and InnoDB table type > with command BEGIN ,COMMIT and ROLLBACK successfully. Nice to hear that! I'm VERY interested in your further results, especially performance and reliability. Would you care to report to this list, please? > I got one line in the log file, > " [mysql] no transcation right now", > what does it mean? The message comes from org.jboss.pool.jdbc.xa.XAConnectionFactory in the method prepareObject. The code tries to assign a connection to a transaction, if one exists, but seems to allow usage of the connection outside a transaction. I guess, you are getting a connection in a beans method with a transaction attribute of Supports, Never or Notsupported, do you? Or might be, you get a connection somewhere in your test code, where no transaction at all is established (i.e. from a servlet)? Hope this helps Georg ___ ___ | + | |__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
Re: [JBoss-user] help needed!! Can't create Primary Key class
Hi Malia, > I am getting error when trying to run a session bean that > creates an entity bean. ... > java.rmi.ServerException: Could not create primary key; > nested exception is: > java.lang.InstantiationException: ScheduleBeanPK The java.lang.InstantiationException is | Thrown when an application tries to create an instance of a | class using the newInstance method in class Class ... The JavaDocs for Class.newInstance() state: | Throws ... InstantiationException - if this Class represents an | abstract class, an interface, an array class, a primitive type, | or void; or if the instantiation fails for some other reason. I guess, your 'other reason' is, that you have no public no arg constructor in your PK class, as required by EJB specs 1.1 section 9.4.7.2 (read also 9.2.9). Hope this helps Georg ___ ___ | + | |__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
Re: [JBoss-user] JBOSS SERVER STARTS WITH SYNTAX ERROR -- HELP
Hi Windows users, > When I trying to start server by executing run.bat > file ,it does start but it gives syntax error twice > before giving various pages of output. I've seen similar questions on this list. First thing to do with syntax errors or 'command not found' or similar messages from the batch files is to comment out / remove the initial '@echo off', so that you can see which batch line produces the error, then often only some intuition is neccessary to correct the problem. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] no transaction right now
Hi again Marcel,
now being able to look at your code I can add some comments:
>...
>ResultSet resultSet = null;
>
>try{
>String insertStatement =
>m"INSERT INTO formulier (invoerdatumtijd, voorletters, " +
>"tussenvoegsel, naam, adres, postcode, woonplaats, " +
>"telefoonDag, telefoonAvond, geboortedatum, geslacht, " +
>"email, groep, vrijeInvoer) " +
>"VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)";
>
>PreparedStatement prepStmt =
>this.connection.prepareStatement(insertStatement);
>
>prepStmt.setTimestamp(1, invoerdatumtijd);
>...
>prepStmt.setString(14, vrijeInvoer);
>
>resultSet = prepStmt.executeQuery();
1) --^
>prepStmt.close();
2) --^
>}
>catch(SQLException e){
>if (DEBUG) {
>System.out.println("SQLException in FormBean.insertRow");
>System.out.println(e.getMessage());
>} // end of if (DEBUG)
>throw e;
>}
>finally{
>return new Long(resultSet.getLong("id"));
3) --^
>}
> }
1) your query is a simple INSERT, the only result from an insert
with ANY relational DB is the count of rows inserted. Typically
one would use prepStmt.executeUpdate() which returns int (the count
of rows affected by insert, update and delete, 0 otherwise). You
CAN use executeQuery and the statement will be executed against
the DB (and even successfully, as you see), the method is defined
to return a not null ResultSet, so it will do so ... but no DB
will give back a row from an insert, so the ResultSet you get
will be empty (resultSet.next() will return false)!
2) prepStmt.close() will close the resultSet too, as you migth
easily read from the JavaDocs.
3) before accessing a ResultSet you MUST do a ResultSet.next()
and only if it returns true you are allowed to do a getWhatever
on it. And, as the finally block even is executed in case of
an Exception, how do you expect the ResultSet then to contain
usefull contents? At this place some RuntimeException will be
thrown in every case (probably NullPointerException) in your
code, as the ResultSet's position is before the first row.
Typical idioms for working with ResultSet are:
// build a query returning rows from the DB
// i.e. a SELECT or a stored procedure ...
resultSet = prepStmt.executeQuery();
// ... then, when expecting 0 to many rows ...
while (resultSet.next()) {
resultSet.getThis(...
resultSet.getThat(...
}
// ... or, when expecting exactly one row ...
if (resultSet.next()) {
resultSet.getThis(...
resultSet.getThat(...
}
else {
// handle error
}
The close of ResultSet, Statement and Connection typically are
done in the finally block, so they get closed even in case of
an error. Have a look at the JDBC tutorial from SUN.
I still guess, you are using MySQL's AUTO_INCREMENT and expecting
it somehow to be returned automagically. As I mentioned before,
you have to do it by hand, after inserting your row into a table
with an AUTO_INCREMENT column via executeUpdate() do something
similar to:
String query = null;
try {
// do your insert stuff here with executeUpdate()
...
// retrieve the auto incremented value
query = "SELECT LAST_INSERT_ID()";
prepStmt = connection.prepareStatement(query);
resultSet = prepStmt.executeQuery();
if (resultSet.next()) {
return new Long(resultSet.getLong(1));
}
else {
throw new Exception("Expected one row, didn't get it!");
}
}
catch (SQLException se) {
throw new Exception("Could not execute '" + query + "': " + se);
}
finally {
try {
if (prepStmt != null) {
prepStmt.close();
}
// close connection to give it back into the pool
// to save resources
//if (connection != null) {
// connection.close();
//}
}
catch (SQLException sqlex) {
// empty by intention
}
}
And a final note: it is good practice to close the connection
when done with the work, connections are a very expensive
resource and are tight, you can't have a connection in every
bean instance for it's whole lifetime, which may be weeks. The
connection.close() in JBoss pooled connections actually does
NOT close it really, but instead returns it into the pool to
be available for the next bean instance, that needs one. Be
aware though, between your INSERT and the corresponding
SELECT LAST_INSERT_ID() you must NOT close the connection, as
the last_insert_id() in MySQL is connection based and will
not work properly with different connections.
regards
Georg
___ ___
| + | |__Georg Rehfeld Wolt
Re: [JBoss-user] no transaction right now
Hi Marcel, > I have a question regarding an error I get. In a JSP page I use a > regular Java bean. Some properties are set and at the end I call the > bean's create() methode to actually create a new EJB Entity bean. > Creating the EJB fails: I get the error attached to the end of this > message. Now the funny part is that the database contains the new EJB > data. The question I would like to ask you: where to look for the solution? > ... > I have a feeling that my mySQL transaction management is not > configured properly. These are my mySQL settings in jboss.jcml If you are using mySQL's default with ISAM or MyISAM table types, there is NO transactional support, the MySQL docs tell in length about that issue, why they don't do it and how to code apps that don't require transactions and still try to be safe. It's not, that I agree with all their arguments, I think, transactions are important, especially in the EJB context (where all the tricks, they give, can't be done), but one has to accept that. Having no transactions (and no referential integrity) at the DB level is one reason for MySQL beeing very fast. So, when your error in the EJBean happens AFTER the DB has done a successfull INSERT, it isn't funny at all that the record exists in the DB, even when JBoss does a rollback. But since version 3.23.15 (2000/05/09) they have the BDB table type (quote from the MySQL docs): | 8.5.1 Overview over BDB tables | | Berkeley DB (http://www.sleepycat.com) has provided MySQL with a | transaction-safe table handler. This will survive crashes and | also provides COMMIT and ROLLBACK on transactions. And lastly they adopted just another table type 'InnoDB', looking very promising to me, which is transaction safe and seems to be very fast too, see http://www.mysql.com/doc/I/n/InnoDB.html. I didn't try one or the other up to now, please do it and report us about robustness and speed :-) > ... > [Form] javax.ejb.EJBException: ejbCreate: null > [Form] at nl.inpact.stam.ejb.form.FormBean.ejbCreate(FormBean.java:168) A blind guess is, that you don't return a valid primary key from your ejbCreate(...) method, as it is neccessary with BMP, so the insert already is done, when the container realizes an error. And another blind guess is, you use the MySQL AUTO_INCREMENT feature with your primary key column. With BMP you might do that, but you have to fetch the auto incremented value back into your bean (MySQL 'select LAST_INSERT_ID()') and return it as a primary key class instance. Instead of that, consider some sort of KeyGenerator, see other threads on this list. Hope this helps Georg ___ ___ | + | |__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
Re: [JBoss-user] CMP and CMT: when does the commit happen?
Hi Roman > When does the commit happens in case of container managed transaction > Required: ? Depends on the caller/client already having a transaction or not. If it has, the method executes in that TX context and there is no commit at method return time. If the client has no TX the container creates one, executes the method and just before returning to the client commits. > RequiredNew: ? Ever on method return time, since, when the client already has a TX, the container suspends it, creates a new one, executes the method in that new TX and commits it at return time, but resumes the old clients TX. If the client has no TX, the container behaves as with Required. regards Georg ___ ___ | + | |__ 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
Re: [JBoss-user] multiple key
Hi Andrea, > I want to use a beans who maps a table on a relational db which haS a > primary key composed by two colomns of this table, or eventually a column of > this table and a column which is a foreign key which point on another table. > This is may little problem; I don't understand if with JAWS I may do this, > or I has to use a BMP. We currently use BMP only and havn't touched JAWS yet, so I tried a search in the JBoss docs, on the JAWS mailing list archive and in the JBoss code. Neither in the docs nor in the archive I could find a clear answer (though in the archive there are similar questions -- unanswered :-( ). In the code I found (in org.jboss.ejb.plugins.jaws.jdbc.JDBCCreateEntityCommand) handling for a 'composite key' while creating an EntityBean. So I assume that JAWS is able to work with composite keys. I think it works as follows: when you want to have a composite key you must have a handmade primary key class, which must follow the EJB spec 1.1 section 9.4.7.2 (and 9.2.9). Important is to have each PK class field public and with the same name and type in both, the PK class and the bean. In ejb-jar.xml do NOT fill in the primkey-field element of the deployment descriptor, but the FILL in the prim-key-class element. The rest should be handled automatically by JAWS. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] mySQL auto increment and CMP entity beans
Hi Paul, > The code I am using is as follows, I had thought of creating an additional > bean to do this but was wondering if there was an easier way. >[code cut, see Pauls mail] > [Section] java.lang.Error: id may not be null > [Section] at org.jboss.ejb.CacheKey.(CacheKey.java:51) > [Section] at > org.jboss.ejb.plugins.EntityInstanceCache.createCacheKey(EntityInstanceCache > .java:47) >[rest of trace cut] This exception is thrown in the container, not in JAWS. So you only have the chance to use a KeyGenerator(). And again reading the EJB spec 1.1 section 9.4.2 paragraph six I found: | The container may create the representation of the entity in the | database immediately after ejbCreate(...) returns, or it can defer it to | a later time (for example to the time after the matching | ejbPostCreate(...) has been called, or to the end of the transaction). So, to remain portable to other EJB implementations, you even havn't the chance to use ejbPostCreate to access the autoincrement value, as the DB access might have not been done already (though with JAWS the insert is done between ejbCreate and ejbPostCreate). regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: In one of my earlier mails (on another but similar thread in this list) I argued against Marc Fleurys proposal of a 'mixed mode' entity bean, where the bean is essentially CMP but the create methods (and finders) are BMP. I must have been too tired at the time of writing that, a 'mixed mode' would help a lot with autoincrements and sequences. See http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg04776.html ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re: Multiple Remote EJB Requests Bombs JBoss
Hello Guy, Toby, Jonathan, and all other users/developers, Jonathan said: >>> ..., many other application servers automatically >>> return the connection to the pool at the end of a transaction. >>> I would like to see this implemented by JBoss, since it kinda >>> of makes sense. Toby promised: >> And see it you will. This is on my todo list, albeit at low priority. Guy finally argued: > Hmm, I see a potential problem with this. > What if I have logic like this: > > Get a whole bunch of data from somewhere. > Get a database connection. > For each record > Do a whole bunch of database work > Commit >If database work failed > Log an error >Continue > > This is a pretty common scenario. If you return the connection > to the pool once the transaction is finished, this code won't > work. I agree with Guy, invalidating a connection at the end of a transaction without request seems to be bad behaviour, especially in case the transaction commits successfully. If the bean throws some exception, I'm sure to have seen at least one place, where the EJB spec _requires_ the bean to be operational even after the failure, letting the bean implementor do appropriate corrections (that simple 'Continue' above). I'm too tired to look it up right now, just let me remember, that it depends on the Exception type, if the beans instance should be thrown away or left alive. And 'left alive' clearly means all state, not directly concerned with the failure, must survive. On the other hand, I know of many database systems, that are unable to keep statements (so called cursors) in progress open spanning a transaction boundary (in fact, Oracle is the only DB I know of for sure to be able to do that), may be, that is the reason to end all things at transaction end time? But then, this should be handled behind the scenes in JAVA EJB, hiding DB implementation details. May be, the whole thing is tied to the lack of true XA compliant JDBC drivers? Have a nice day Georg ___ ___ | + | |__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
Re: [JBoss-user] Interesting test of JDBC pooling
Hi Brian, > Here is the source for the session bean using connection pooling: as others pointed out and you confirmed them to be right, giving back the connections into the pool by executing connection.close() speeds up your processing essentially. But you not only test the speed of the connection pool, but at the same time the speed of a JNDI lookup: your getName() calls getConnection() which in turn not only gets the connection but also creates a new InitialContext and does a lookup of your datasource. I would do the InitialContext.lookup() thing only once and cache the DataSource to avoid further lookups. Pooled are the Connections, that is the tight resource, not the DataSource. And I would be very interested in your test results after that modification, so we all can better see the overhead of lookup vs. connection pooling. ___ ___ | + | |__ 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
Re: [JBoss-user] mySQL auto increment and CMP entity beans
Hi Paul, > I am using jboss 2.2.1 to create a simple CMP entity bean that has two > properties, id and name. In the database the id is an auto increment > column. In the bean managed version of this bean I had a second sql > (select ns.section_id from nh_section ns where ns.section_id is null) > call to get the id of the row just added. In the CMP version I am not > setting the id so on return from the ejbCreate method the container > gives an exception saying the id cannot be null. Is there a way in > container managed persistance beans to get jaws to find out the id of > the inserted row and set the id property to this value. Without a stack trace, I can't decide, if this really is the container complaining about a NULL or if it is JAWS having problems to insert the NULL. But even without knowing that you might have a problem. JAWS seems currently not to be able to do more than the default in create methods (extracting the beans fields and executing a SQL insert from it), which is a pitty. As of the EJB spec 1.1 section 9.5.2 figure 27 the CMP container extracts the beans fields, stores them to the DB and constructs the EJBObject (and thus the primary key object) immediately after return from ejbCreate and before calling ejbPostCreate and so it only has the opportunity to extract your beans public pk field at that point to fill in the primary key classes field, which yields a NULL setting in the PK. So ejbCreate with CMP is too early to access the DB for retrieval of your autoincrement value (nothing is stored at that time) and ejbPostCreate is too late, as the primary key object already is created. If the exception is really thrown at the return of ejbCreate and isn't a JAWS exception but a conainer exception, you don't have the opportunity to try to set the autoincrement in ejbPostCreate into both, your beans field and the PK objects field. Else you might try that (though I'm totally unaware of the consequences, that looks not to be spec conform to me). What you might try is another approach (we use that with BMP): in ejbCreate use some key generation mechanism to set your beans PK field, a simple one, similar to your current approach, is to use a sequence table with MySQL autoincrement values. The table has essentially 2 columns, one for the table name you want a new sequence value for and another one defined to be autoincrementing and holding the next key to use. This could be nicely hidden in some KeyGenerator class with some method like getNextKey(String tableName). As of the EJB spec this should be allowed, as the ejbCreate method may execute everything as a business method may execute (except accessing EJBObject and the Primary Key). Besides, have a look at theserverside.com for different key generation patterns. This key generator could be written as a BMP or as a stateless session bean or even as a simple class. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] multiple key
Hi Andrea, > question:There is a way to map a primary key over multiple > tables in a db? I'm not quite sure, what you mean: - having the same primary key _column_ name/type in different tables? This is definitely allowed in SQL. - using the same primary key _class_ in different beans? This is allowed, see EJB spec 1.1 section 8.5 and illustratet by the fact, that i.e. java.lang.Integer is a valid primary key class. - having one bean stored 'horizontally' splittet over several tables, which share the primary key (i.e. so, that heavily used fields/columns are stored in a fast DB and others in a slower (remote) one)? I don't think, you can do this currently with JBoss CMP (using JAWS), but I may be wrong (we use BMP here). Others may correct this statement. With BMP you can do this split easily, and in ejbLoad either join the data together to fetch them in just one JDBC call, or only load the important fields from the fast DB lazily loading the rest from the slow DB in the apropriate business methods. - having one bean stored in different tables 'vertically' i.e. depending on some type field (so as to store old data into a DB on a cheap slow server with high data capacity and actual data into a DB on an expensive fast server with limited data capacity)? Again I believe, this is currently impossible with JAWS CMP. And again, you may easily do that with BMP, if you have your tables in one DB you might use the SQL UNION syntax to access all tables with only one SQL statement in ejbLoad, or query all tables until you've found your row back (if you can't decide from the primary key, where to search for the data). If I misunderstood you completely, please clarify. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] Overriding CMP entity creation
Hi Dan, > If all you need to do is get your primary key from the autoincrement, > you can simply put the code to fetch the value in ejbCreate and return > that value as your primary key. Or am I missing something? yes, I think so, Ray has essentially a CMP bean, and EJB spec 1.1 in section 9.5.2 figure 27 shows, that ejbCreate() is called before the container accesses the DB; section 9.4.2 additionally says, that ejbCreate(...) should be DECLARED to return the PK class but actually to return null, as the container is required to ignore that return value. If a DB autoincrement mechanism is desired at all JAWS has to handle that (i.e. with JRun's EJB part, formerly known as Ejipt, it is possible to configure many SQL statements to be executed for every CMP action instead of only one, thus allowing an 'insert ...' followed by a 'select ...' or a '...CURVAL...' or a stored procedure). But from previous messages I believe, Ray was pointed to theserverside.com (and there to something like the High-Low key generating pattern) and interpreting Marcs answer in this thread I'm pretty sure, this is the intention: the bean itself creates a new key 'magically'. What I think isn't needed for Rays problem is Marcs suggestion of a 'mixed mode'. SUN clearly has intended the ejbCreate(...) method for proper initialization of all bean fields (section 9.4.2, 3rd paragraph) and has allowed ALL access as for every business method (EXCEPT ctx.getEJBObject() and ctx.getPrimaryKey(), which don't make too much sense here [section 9.1.6, Table 4]) in ejbCreate(). Thus Ray is free to implement whatever he needs to compute a primary key and assign it to his PK field(s), including access to some DataSource and incrementing/reading DB values from it, as some key generating mechanisms require (section 9.1.6, Table 4 definitely allows 'JNDI access to java:comp/env')! But may be, I'm missing the point, do I? my very best regards Georg ___ ___ | + | |__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
Re: [JBoss-user] ejbFinder problem
Hi Jim, > Yes, exactly so. I should have made it clear, sorry. The naming > convention is XXXHome and XXX are the home and remote interfaces, and > XXXBean is a value object that conforms to the JavaBean spec (required > further on in the app). > > The id field is constrained as a primary key - I was under the > impression that this implied that nulls were not permitted. I assume you mean in the database: not neccessarily, a 'primary key constraint' usually implies a 'unique constraint' on the primary key columns, thus, with one column only in the PK, one NULL PK row migth be allowed; with a 2 column PK 'NULL, NULL' 'x, NULL' and 'NULL, x' might be all interpreted different as unique PK values, will depend on the DB used, Oracle i.e. accepts NULL values in PKs. But this seems not to be the problem at all ... > So the problem seems to be that the remote interfaces in the collection > returned by findAll seem to have lost their record of the id of the bean > they represent. Is this to do with my use of value objects? Is it > necessary to have a simple getter for the primary key on the remote > interface? No, neither with CMP nor with BMP (which you told us to use); though, with CMP you had to have a public PK field, which the container accesses to read and write. But with BMP YOU are responsible to load and store the bean instances state, whether you use simple fields only in your bean or a value object or both. In your original message you've given neither a stack trace nor indications of your ejbLoad()/ejbStore()/ejbFindAll() methods, you didn't show us the constructors of your value object. Is it a true value object (no setters)? Consider giving us more precise information, then it might be someone sees the error and we haven't to guess most of your problem. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] JBoss hangs ...
Hi Ray, > I've tried to execute a context.getEJBObject and a context.getEJBHome > within an ejbPostCreate call > > But for some reason, this hangs JBoss. > > According to most stuff I've read, I should be able to use the > context inside ejbPostCreate. You are right, according to EJB spec 1.1 section 9.1.6 'Operations allowed in the methods of the entity bean class' you are definitely allowed to call both methods from ejbPostCreate(). Could you post your code, please (ejbCreate, ejbPostCreate). If you are absolutely sure to do it the right way, consider reporting that as a bug at SourceForge: http://sourceforge.net/tracker/?atid=376685&group_id=22866&func=browse regards Georg ___ ___ | + | |__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
Re: [JBoss-user] CMP and auto_increment
Hi Ray,
> I have a table which has an auto incrementing field, and I'm accessing it
> using a Contaimer Managed Bean
>
> If I want create a new record, I just call rec.create("title"); I don't
> bother with setting the id number because it's generated automatically.
>
> Now I reckon that I still need a setID method, so that the bean can
> retrieve the number when I do a findBy but how do I stop others from
> calling the setID, and messing up the id number?
make the setId() method private or protected, as you only access
it from ejbFindBy from inside the bean; don't expose it into
the remote interface of your bean -- or even simpler, directly
assign to your CMP field 'id'. This way 'official' spec conform
clients can't write access your bean's id field.
Note however, that write access from some arbitrary helper classes
running on the EJB server side can't be restricted, as CMP fields
must be declared public as of the EJB specification 1.0 and 1.1
(that changes in 2.0)!
regards
Georg
___ ___
| + | |__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
Re: [JBoss-user] EJB 1.1 throws RemoteException deprecated
Hi list, > Hi Toby, ... read it again CAREFULLY please: Sorry, sorry, I meant Norton. best regards Georg ___ ___ | + | |__ 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
Re: [JBoss-user] EJB 1.1 throws RemoteException deprecated
Hi Toby, > You're right. I should have looked up the EJB 1.1 spec, > but I was lazy. Since you called me on it, I looked > up the spec. ... (See section 12.3.7. ... Here is the quote from the spec, read it again CAREFULLY please: | 12.3.7 Support for deprecated use of java.rmi.RemoteException | | The EJB 1.0 specification allowed the business methods, ejbCreate, | ejbPostCreate, ejbFind, ejbRemove, and the container-invoked | callbacks (i.e. the methods defined in the EntityBean, SessionBean, and | SessionSynchronization interfaces) implemented in the enterprise bean | class to use the java.rmi.RemoteException to report non-application | excep-tions to the Container. | | This use of the java.rmi.RemoteException is deprecated in EJB | 1.1 -- enterprise beans written for the EJB 1.1 specification should | use the javax.ejb.EJBException instead. | | The EJB 1.1 specification requires that a Container support the | deprecated use of the java.rmi.RemoteException. The Container should | treat the java.rmi.RemoteExcep-tion thrown by an enterprise bean method | in the same way as it is specified for the javax.ejb.EJBException. | | Note: The use of the java.rmi.RemoteException is deprecated only in the | above-mentioned methods. The methods of the remote and home interface | still must use the java.rmi.RemoteException as required by the EJB | specification. > So my question now changes to: Is the requirement > that is specified by JBoss 2.2.1 (...) upon deployment > a design decision or an oversight? It is correct behaviour (as Lennart Petersson already pointed out): the BEAN must NOT throw RemoteException, the REMOTE and HOME interface MUST throw it. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] CMP persistance after shutdown
Hi Steve and Phil, Steve wrote: > The tag must be set to Required, RequiresNew, or > Mandatory or JBoss won't persist your beans. ... IMHO you are right. > the EJB 1.1 spec isn't > trmendously clear how this should be handled. Change the transaction > attribute + things should work fine. I think the spec is VERY clear, here is the quote: | 9.1.7.1 ejbLoad and ejbStore with the NotSupported transaction attribute | | The use of the ejbLoad and ejbStore methods for caching an entity | object's state in the instance works well only if the Container can use | transaction boundaries to drive the ejbLoad and ejbStore methods. When | the NotSupported transaction attribute is assigned to a remote interface | method, the corresponding enterprise bean class method executes with an | unspecified transaction context (See Subsection 11.6.3). This means that | the Container does not have any well-defined transaction boundaries to | drive the ejbLoad and ejbStore methods on the instance. | | Therefore, the ejbLoad and ejbStore methods are 'unreliable' for the | instances that the Container uses to dispatch the methods with an | unspecified transaction context. The following are the only guarantees | that the Container provides for the instances that execute the methods | with an unspecified transaction context: | | - The Container invokes at least one ejbLoad between ejbActivate and the | first business method in the instance. | | - The Container invokes at least one ejbStore between the last business | method on the instance and the ejbPassivate method. | | Because the entity object's state accessed between the ejbLoad and | ejbStore method pair is not protected by a transaction boundary for the | methods that execute with an unspecified transaction context, the Bean | Provider should not attempt to use the ejbLoad and ejbStore methods to | control caching of the entity object's state in the instance. Typically, | the implementation of the ejbLoad and ejbStore methods should be a no-op | (i.e. an empty method), and each business method should access the | entity object's state directly in the database. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] Looking up a certain StateFul Session Bean
Hi Kris, > The problem I encountered was that a specific StateFul session > bean had to be called from more than one other bean/application. The EJB Spec definitely does not allow access from more than one application to a stateful session bean instance: | EJB spec 1.1 | | Chapter 6 Session Bean Component Contract | | 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. | | One implication of this rule is that an application cannot make | loopback calls to a session bean instance. This also explains, why there is no lookup() for a specific stateful session bean instance. Though you could try to pass a reference or a handle to the instance around, be aware of the quoted implication (no loopbacks). You didn't explain, why your stateless session instance wants to access the statefull one. If it is not interested in client specific state kept in the stateful instance, but needs some service, consider extracting the service methods into a normal class (i.e. a Singleton) or a stateless session bean and use the service from both beans. If it is the clients state, you are interested in, you must redesign, so that the statfull instance is the 'driving' part and reaches in the neccessary state as parameters. regards Georg ___ ___ | + | |__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
Re: [JBoss-user] Transaction blocks forever, LOCKING-WAITING
ctionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) Thanks and regards Georg ___ ___ | + | |__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
Re: [JBoss-user] Transaction blocks forever, LOCKING-WAITING
Hi all,
since my original posting I upgraded from 2.1 BETA binary
distribution to the 2.2.1 binary distribution of JBoss and
testet again:
The problem essentially remains, the sequence of accesses has
changed a little, I can now access several beans in the first
place, but after a short while I again get a block in the JNDI
lookup() method followed by a transaction timeout message but
with no exception raised. The entity bean remains associated
with the transaction for ever; the next access to it again
produces the millions of 'LOCKING-WAITING (TRANSACTION)'
messages and only a server shutdown helps.
Are we doing it wrong, is a JNDI lookup inside a transactional
business method forbidden? Any other suggestions?
Thnaks in advance
my best regards
Georg
___ ___
| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
- Original Message -----
From: "Georg Rehfeld" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 4:36 AM
Subject: [JBoss-user] Transaction blocks forever, LOCKING-WAITING
> Dear Helpers,
>
> while testing JBoss 2.1-BETA we experience this problem:
>
> the second sequence of calls (non concurrent) from a servlet to a
> bean blocks forever, the servlets doGet() Method never returns.
>
> - scenario (environment and config see below), shown is part of
> the servlet doGet() method sequence (and the 1:N association
> between Profile and Area)
>
> servletbean(BMP) bean(BMP)
> +-+ +-+ 1 * +--+
> | ProfileTest | | Profile |--| Area |
> +-+ +-+ +--+
> #| |
> # findByPrimaryKey() | |
> #---># |
> #| |
> # getData() | |
> #---># |
> #| |
> # getAreas() | |
> #---># jndiCtx.lookup("Area")
> ##->
> ## |
> ## findAreas() |
> ##->#
> #| |
> # *getData() | |
> #-->#
> || |
>
> First time the doGet() method completes fine and displays the one
> Profile and all the Areas associated, and so there should be no
> transaction open at all. However, when the servlet is invoked again
> (to access a different Profile) the call blocks in
> Profile.getAreas()-->jndiCtx.lookup("Area"), which is totally
> unexpected for us. Neither should be any transaction pending,
> since the first doGet() and all invoked bean methods completed
> successfully, nor we expected the JNDI context to be a transaction
> aware resource, at least the lookup() method is readonly.
>
> Nevertheless, we get, after a while, this log entry:
> [Profile] Transaction XidImpl [FormatId=257, GlobalId=reathome//5,
> BranchQual=] timed out. status=STATUS_ACTIVE
>
> But even after that message the Profile instance hangs waiting for
> the AreaHome reference from JNDI, the servlets doGet() method
> doesn't complete and the second Profile instance remains associated
> to a transaction. No exception is thrown, JBoss simply hangs around.
>
> When we after that try to access the first Profile bean again or
> some other Profile bean, surprise, surprise, all works fine again,
> all calls complete nicely, if there are associated Area instances
> or not and how many Profiles we try to access.
>
> But when we attempt to access the second Profile instance another
> time, we get that infamous 'LOCKING-WAITING (TRANSACTION)' log
> message with all the bad consequences (CPU usage > 90%, server.log
> grows immediately to tons of megabytes until out of disk space, only
> a JBoss shutdown helps, as this lock seems never to be released, but,
> please, don't focus your answers on this, there is help underway
> already, see this mailing list's archive and the PS2).
>
> Anyone out there, who can help or suggest? Thank you!
>
> --
>
> - relevant code:
>
> public class ProfileBean {
> ...
> /** Returns a Collection of Area beans. */
> public Collection getAreas() throws RemoteException {
> debug("getAreas()");
> if (areas == null) {
> AreaHome areaHome = null;
> try {
> Context ctx = new I
Re: [JBoss-user] Anyone know how to federate across multiple jnp ...
Hi all, Guy Rouillier wrote: > Scott, thanks very much for the explanation. The reason I am doing this is > that for security purposes, we want to move as much as possible off the > standard ports (we'll have a firewall.) Is there anywhere an all-inclusive > list of the ports that JBoss uses (out of the box - er, zip - I realize > JBoss allows additional functionality to be plugged in), and how to change > them? ... A list of used ports can be found in the JBoss online docs at http://www.jboss.org/documentation/HTML/ch10s03.html regards Georg ___ ___ | + | |__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] Transaction blocks forever, LOCKING-WAITING
BUG: doGet() GETTING AREAS [Profile] ==> DEBUG(ProfileBean)[prf_pk:206] getAreas() [Profile] ==> DEBUG(ProfileBean)[prf_pk:206] getAreas(), looking up AreaHome [Profile] ==> DEBUG(ProfileBean)[prf_pk:206] getAreas(), finding areas for profile [Area] ==> DEBUG(AreaBean)[] setEntityContext() [Area] ==> DEBUG(AreaBean)[] ejbFindAreasForProfile(int profileId) [Profile] ==> DEBUG(ProfileBean)[prf_pk:206] ejbStore() skipped [EmbeddedTomcat] >>> (ProfileTest) DEBUG: doGet() END = ### second access, no associated Areas, HANGS [EmbeddedTomcat] >>> (ProfileTest) DEBUG: doGet() START == [EmbeddedTomcat] >>> (ProfileTest) DEBUG: doGet() FINDING PROFILE BY PK [Profile] ==> DEBUG(ProfileBean)[] setEntityContext() [Profile] ==> DEBUG(ProfileBean)[] ejbFindByPrimaryKey() [EmbeddedTomcat] >>> (ProfileTest) DEBUG: doGet() GETTING PROFILE DATA [Profile] ==> DEBUG(ProfileBean)[prf_pk:600] ejbActivate() [Profile] Activated bean Profile with id = prf_pk:600 [Profile] ==> DEBUG(ProfileBean)[prf_pk:600] ejbLoad() [Profile] ==> DEBUG(ProfileBean)[prf_pk:600] ejbStore() skipped [EmbeddedTomcat] >>> (ProfileTest) DEBUG: doGet() GETTING AREAS [Profile] ==> DEBUG(ProfileBean)[prf_pk:600] getAreas() [Profile] ==> DEBUG(ProfileBean)[prf_pk:600] getAreas(), looking up AreaHome ### time passes ... [Bean Cache] Scheduling for passivation overaged bean Profile with id = prf_pk:206 - Cache size = 2 [Bean Cache] Aging out from cache bean Profile with id = prf_pk:206; cache size = 2 [Container factory] Scheduled passivation of bean Profile with id = prf_pk:206 [Container factory] ==> DEBUG(ProfileBean)[prf_pk:206] ejbPassivate() [Container factory] Passivated bean Profile with id = prf_pk:206 ### [Bean Cache] Scheduling for passivation overaged bean Profile with id = prf_pk:600 - Cache size = 1 [Bean Cache] Aging out from cache bean Profile with id = prf_pk:600; cache size = 1 [Container factory] Scheduled passivation of bean Profile with id = prf_pk:600 [Container factory] Postponed passivation of bean Profile with id = prf_pk:600 ### last 4 messages repeated 2 times [Profile] Transaction XidImpl [FormatId=257, GlobalId=reathome//5, BranchQual=] timed out. status=STATUS_ACTIVE ### [Bean Cache] Scheduling for passivation overaged bean Profile with id = prf_pk:600 - Cache size = 1 [Bean Cache] Aging out from cache bean Profile with id = prf_pk:600; cache size = 1 [Container factory] Scheduled passivation of bean Profile with id = prf_pk:600 [Container factory] Postponed passivation of bean Profile with id = prf_pk:600 ### last 4 messages repeated forever - relevant environment and configuration: [Info] Java version: 1.3.0,Sun Microsystems Inc. [Info] Java VM: Java HotSpot(TM) Client VM 1.3.0-C,Sun Microsystems Inc. [Info] System: Windows 2000 5.0,x86 [Default] JBoss 2.1-BETA Started in 0m:7s [binary distribution] Tomcat is jakarta-tomcat-3.2.1 standardjboss.xml modified to use MySQL datasource All beans use BMP, all methods are marked as transaction CM and 'required'. No 'jboss.xml' used. Servlet(s) and beans are packed in jar/war/ear and deploy without warning or error. The behaviour is repeatable anytime with our current code, I'll freeze it, in case someone needs access to it for analysis. Thanks in advance for your help, regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: We are happy to have JBoss and all it's developers, contributors and helpfull users, you all are doing nice work! PS2: For the LOCKING-WAITING problem there were 2 corrections proposed, both to org.jboss.ejb.plugins.EntityInstanceInterceptor: one beeing a task sleep, which reduces CPU usage essentially, and the other one (published on this list) reporting only the start and the end of a lock synchronization instead of every failed lock attempt. In the current CVS (May 7th 2001) I can't find neither of them. Does somebody know, when these corrections will be made public? ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
