Re: [JBoss-dev] jaws_2_4.dtd not valid
You can have only one definition of the datasource element - and that's all we need since it's the same either place (just contains CDATA). As long as it's listed as a possible contained element for both the global jaws element, and the entity-bean element, we should be fine. Unless I'm missing something. -danch Vinay Menon wrote: > Mike, > That is a bean level datasource and quite obviously cannot be commented > out in principal! I mean if you got to have a bean level ds you got to have > one! Client programs should be able to define a datasource at the file level > i.e. applicable to all the beans declared in the jaws.xml and the datasource > at the bean level essentially overrides it. > > Vinay > > - Original Message - > From: "Mike Swainston-Rainford" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 11, 2001 11:40 PM > Subject: [JBoss-dev] jaws_2_4.dtd not valid > > > >>the jaws dtd is no longer valid. The datasource element is defined twice. >>This mucks up any validating editor/parser (like XMLSpy) used to edit a >>jaws.xml file. >> >>Suggest the second definition at line 69 is a comment thus:- >> >> >> >> >>Mike S-R >> >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>http://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] xml config for Log4j
With config files changing names, we should probably fork the docs (2.4 fork and 3.0 docage on the main) soon. -danch marc fleury wrote: > Now that I (almost) done with the container synchronization rewrite, I am > going to commit the JBoss 3.0 code that I have on my laptop, if I remember > correctly I move most of the stuff to services.xml (the old jboss.jcml) and > log4j should go there, will try to commit this piece by next tuesday > > marcf > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] remove transactional
I agree with Bill - removing everything involved in the rolled-back transaction from the cache is a must. -danch Bill Burke wrote: > Nope, with the old code, B would be removed from the cache when b.remove() > was called even if it was invoked from within a transaction. Also, all > beans involved with a transaction would be removed from the cache on a > rollback within InstanceSynchronization. > > I think that is the safe and correct approach to remove any bean from the > cache that is part of a rollback. Otherwise you may have corrupted data. > > Bill > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of marc >>fleury >>Sent: Tuesday, July 03, 2001 2:57 PM >>To: Jboss-Development@Lists. Sourceforge. Net >>Subject: [JBoss-dev] remove transactional >> >> >>as I wrap up the stuff, sanity check >> >>bean a and bean b >> >>a starts transaction and calls b.remove() and then rolls back >> >>b is still there in cache right? >> >>marcf >> >>_ >>Marc Fleury, Ph.D >>[EMAIL PROTECTED] >>_ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Georg Rehfeld wrote: > Hi danch, > > >>Does anybody know what databases are case sensitive WRT column and table >>names (or even keywords). I've never run into case sensitive SQL >>databases before. >> > > MySQL too is case sensitive on database, table and index names > on a case sensitive file system (i.e. xNIX) with some table types > especially the default MyISAM table type. The reason is, that > they simply use the given name to generate a file path from it. > Gak! Well, Vinay's fixed that bug already. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
Dain Sundstrom wrote: > Bill, > > Thanks for the reply. I really need other people thinking about this, > because I don't understand the rest of the container. > > Here's the deal. I delegate the actual storage of the other updated > contexts to the their respective persistence storage managers, so they get > stored by correct data source. I also get references to the other beans > through their container's cache. Errr. I was nervous enough about the persistence manager messing with its own bean's cache, let along messing with other bean's caches. > > I think the biggest problem with this implementation is that my persistence > store is directly calling store on other persistence stores, thus by passing > all of the code that is supposed know the right way to do this. Ya, this makes me nervous too - there's too much that can go wrong. Really to get the store going you should be hooking into the transaction (which is the job of the EntitySynchronizationInterceptor) What about Bill's suggestion to go through the homes? That may not be the best performance, but then you know that all the Right Things are happening, even if (when) the definition of Right Thing changes. Short circuiting the interceptor chain is bad, IMHO. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
The first implementation of the read-ahead messed around with the caches before I decided that I didn't like it and took that out. -danch Dain Sundstrom wrote: > Jay, > > Great point. Up until I started on this code, no part of JBossCMP worked > with the other container objects (cache, invoker etc); JBossCMP was executed > by the container via the persistence store interface. I'm going to have to > think about this. > > Thanks for helping to clarify my bad feeling, > > -dain > > >>-Original Message- >>From: Jay Walters [mailto:[EMAIL PROTECTED]] >>Sent: Friday, June 29, 2001 2:01 PM >>To: '[EMAIL PROTECTED]' >>Subject: RE: [JBoss-dev] Where is everyone today? >> >> >>I would think you'd want to be out of the guts too, that just >>seems a bit >>too closely coupled with JBoss for the persistence manager. >>Shouldn't the >>CMP persistence manager be some type of layer on top (well >>almost on top) >>with a well defined interface? This should clearly tie in to >>take advantage >>of what the container can provide. >> >>I am definitely on the outside of JBoss though, so marc et al >>are the people >>to listen to. >> >>Cheers >> >>-Original Message- >>From: Bill Burke [mailto:[EMAIL PROTECTED]] >>Sent: Friday, June 29, 2001 2:53 PM >>To: [EMAIL PROTECTED] >>Subject: RE: [JBoss-dev] Where is everyone today? >> >> >>Yo Dain, >> >>I know absolutely nothing about CMP 2.x Relationships, but it makes me >>really worried that you are working directly with >>EntityEnterpriseContexts >>from the container.cache. Why aren't you going through the >>HOME interfaces >>to access related beans? Remember, each entity type can have entirely >>different datastores, caching mechanisms, locking mechanisms, >>synchronization mechanisms, and pooling mechanisms. You >>shouldn't really be >>circumventing how to access a bean. If I'm totally out of my >>league here, >>I'll just apologize and shut up. Let me know, but in the >>meantime, I'll try >>to review the CMP 2.x Relationships. >> >>Bill >> >> >>>-Original Message- >>>From: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED]]On >>> >>Behalf Of Dain >> >>>Sundstrom >>>Sent: Friday, June 29, 2001 2:22 PM >>>To: '[EMAIL PROTECTED]' >>>Subject: [JBoss-dev] Where is everyone today? >>> >>> >>>Is everyone on vacation? Is the list working? What-ever, >>> >>doesn't really >> >>>matter. >>> >>>If any one is around today, and can reply to my message, I >>> >>would greatly >> >>>appreciate it. I kind of need some guidance on the decision >>> >>to create an >> >>>interceptor or not. I'm going to continue along the line that I >>>don't need >>>an interceptor (I can always add it later). >>> >>>If you all are on vacation, have a great time. >>> >>>-dain >>> >>> -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 11:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation marc, Do you mean that I should be setting invoked, or something else? I got the bi-directional one-to-one (enforced integrity) working using the entity cache, but it gives me a bad feeling. In the this case, there may be up to 4 beans that need to be stored: before: a1--b1 a2--b2 a1.setB(b2) after: a1\ b1 a2 \b2 So, I hold onto up to three other contexts. When my store is called, I write my state and then store the other contexts (with their respective mangers). This won't cause extraneous writes as 'tuned updates' is >>always on. >> What is giving me the bad feeling is I have just cut out all of the work that is being done in the interceptors, specifically EntitySynchronizationInterceptor. For example, do I need >>to remove the >> context from the cache at the end of the transaction? Do I need to lock the context? What if one of the beans is removed? (the new remove procedure for relationships may handle this, but haven't implemented it yet) As you can tell this has given me a lot of concern. If >>this is stuff I >> shouldn't worry about, good. If I should worry, will it be better to create the new interceptor, thus reusing the code in the other interceptors, or will it be easier to handle the few special cases in the persistence store? -dain >-Original Message- >From: marc fleury [mailto:[EMAIL PROTECTED]] >Sent: Thursday, June 28, 2001 9:53 PM >To: [EMAIL PROTECTED] >Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > >also be sure to report right here is you touch any of the >information in the >ctx (using setters) > >marcf > >|-Original Message- >|From: [EMAIL PROTECTED] >|[mailto:[EMAIL PROTECTED]]On >Behalf Of Dain >|Sundstrom >|Sent: Thursday
Re: [JBoss-dev] Shutting down JBoss
Vinay Menon wrote: > Alright, > > This might sound a bit naive but do we need a little simple > gui that one can use to shut down JBoss or restart it? When you run > JBoss on the command line in Unix as a background process [./run.sh&] it > spawns loads of java processes that need to be killed. Is there a > cleaner way to do this? > Those aren't processes, they're threads. You only need to kill the root java one (do a `ps axf` and you'll see what I mean by 'root'). As for the first issue, point a browser at http://myserver:8082/ and look at the shutdown mbean. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
But if they're in the same transaction, they must use the same isolation level - per our discussion on the database doing an implicite commit when you try to change levels. I don't think it makes logical sense to talk about having two different transaction isolation levels in the same transaction, either - either the transaction is serializable or the transaction is read-committed. -danch Bill Burke wrote: > I disagreewell, at least for our app, we have transactions where some > entities really need to be serialized and other entities within the > transaction are just fine with read_committed. > > Bill > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of David >>Jencks >>Sent: Tuesday, June 26, 2001 4:43 PM >>To: [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] High load... >> >> >>Hi, >> >>Forgive me if I am talking nonsense, but doesn't it only make >>sense to have >>transaction isolation per transaction I very much doubt you will find >>a db that can support several transaction isolation levels within one >>transaction. I can't quite figure out what it would mean, either. So I >>say, put it with the transaction requirements for methods - Requires, >>Requires New, etc. Then you can set the isolation each time you start a >>new transaction, based on this specification. >> >>david jencks >> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch > Hi, > > Forgive me if I am talking nonsense, but doesn't it only make sense to have > transaction isolation per transaction I very much doubt you will find > a db that can support several transaction isolation levels within one > transaction. I can't quite figure out what it would mean, either. So I > say, put it with the transaction requirements for methods - Requires, > Requires New, etc. Then you can set the isolation each time you start a > new transaction, based on this specification. > > david jencks > > On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: > >>>|I added transaction isolation to the new cmp plugin. You can set it by >>>|adding the element after the datasource >>> >>element. >> >>>|Valid levels are: >>>|transaction-none >>>|transaction-read-committed >>>|transaction-read-uncommitted >>>|transaction-repeatable-read >>>|transaction-serializable >>>| >>>|Give me 10 minutes and I'll add it to JAWS... >>> >>>ok but these will be leveraged by new caches in JBoss 3.0 >>> >>> >>> >>>so I would imagine that each application can set its own datasource >>>isolation level, (different kinds of bean). So it IS user configurable >>>right??? >>> >>>Also how does it play with the datasources, if the datasource is shared >>>across applications and different tables support different locking >>> >>policies >> >>>(say one table is RO the other RW) can the driver support sequential >>>"setIsolationLevel" that only applies to the record and or table >>> >>touched? >> >>>marcf >>> >>> >>Right now this the jaws and jbosscmp code only support datasource per >>application. When we implement datasource per bean, we can have >>isolation >>level per bean. This leads to the intresting situation with EJB-QL >>queries >>that thouch multiput beans. May be we need to specify an isolation lever >>for >>each query. Havn't thought about it much. Right now you can only set it >>for the entire ejb-jar. >> >>Just tell me when you get the cache stuff figgured out and I can update >>jaws >>and jbosscmp to support what ever you want. >> >>-dain >> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Fw: [JBoss-dev] Shouldn't expose transaction-isolation within CMP
Dain Sundstrom wrote: >>I think I understand now. Here is some text I found the J2EE tutorial: >> >> >>You cannot modify the isolation level of a entity beans with >>container-managed persistence. These beans use the default isolation level >>of the DBMS, which is usually READ_COMMITTED. I don't remember the spec saying that the container had to use the database default isolation level. Is this remark more about the RI than what containers in general should do, or did I miss something? >> >>Do not change the isolation level in the middle of a transaction. Usually, >>such a change causes the DBMS software to issue an implicit commit. D'Oh! I'd expected an exception in that case. >>--- >> >>So the code I added probably causes an "implicit commit," which is bad. >>From my very JDBC centric perspective, this should be set in Minerva >>(JBossPool?) and user configurable. I don't know much about the connector >>architecture, so maybe Minerva is the wrong place. >> >>Any way, I think I should roll back my change. I'd agree. >>If you agree marc, just say >>so and it is done. But I'm not marc. >> >>I don't know any thing about Minerva, so if you want that changed, someone >>else would be better suited. If no one wants to do it, I'll look at it. >> >>-dain >> -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: >>>I don't know if you wanted with user configurable, but for now it will >>> > allow > >>>you to play with different levels. I can make it static later. >>> >>> >> >>static? >> >> > fixed > Like at compile time, literally 'static' in the java sense static? Please god, not this again. Remember that the people responsible for care and feeding of JBoss server instances are liable to be system administrators who have just about 0 regard for products that require a recompile just to change a setting. Consider all the neat stuff you can change by catting some value into a psuedo-file under /proc on a linux box. Consider the things people bitch about _not_ being able to change there (per-user process limit, etc.). -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shouldn't expose transaction-isolation within CMP
marc fleury wrote: > |Please correct me if I'm wrong(I seem to be wrong about 50% of the > |time :-), > |but, I really don't think you should expose transaction-isolation levels > |within CMP or in the definition of entities. This really belongs in the > |creation of the connection pool. CMP cannot really guarantee that a > |connection will not be shared between different entity types > |within the same > |transaction that use the same connection pool. Actually, I'm pretty sure > > which is why I am asking if the jdbc drivers support reconfiguration of the > isolation level on the fly or is it pretty much a "constructor" thingy. It's on the fly, but it (generally) has to be set at the beginning of the transaction only. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Bill Burke wrote: > > > Isolation levels and locking are really orthonogal, aren't they? The isolation level is really a hint to the DB as to how you want to lock. > > >>|All in all, I think JBOSS should delegate synching and locking to the DB >> >>sure but my point is that can be a cache decision, if you still want to >>implement a pessimistic cache (like we have right now) with maybe a simple >>"read-only" feature then you can. >> >> > > I still think you should enable the ability to push the pessimistic locking > onto the DB with CMP, or onto the developer for BMP. Or onto the DB with both by associating the isolation level with the connection rather then the JAWS/CMP application, as you suggest on another thread (or is that a branch of this thread?). > In our app, for > instance, we have common, rarely-updated, entities that are shared alot > between transactions. Since the current JBoss code-base locks entities into > a transaction we are forced to use straight JDBC to avoid the unnecessary > locks. I'd really like to avoid mixing JDBC with EJB wherever possible. I > guess this should be put off for 3.0 though... Yup! What if JBoss took the iso. level at a higher level and used it to indicate cache behavior as well - serializable means either pessimistic lock at the database with multiple instances/identity, or transaction block with single instance per entity? > -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: > > I don't know if you wanted with user configurable, but for now it will allow > you to play with different levels. I can make it static later. > static? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: >>>So if we remove the passivation cache, do we loose commit Option A? If >>> > not, > >>>how do we keep bean data alive while passivated? >>> >>>I still may not understand this. >>> >> >>I think Mark is just suggesting losing the passivation part of the >>cache. The cache we keep, it just keeps growing and growing and growing. >> >> >>-danch >> >> > > I find that hard to believe. Would we reboot the server to cear the cache? I > thought he was suggesting removing the cache and just passivating the beans. That would nail us to commit option C. In the light of his remarks on 1GB RAM machines, I find that hard to believe. > I don't want to put words into marc's mouth so hopefully he will expand on > his suggestion. > Hope so, 'cause now we're both guessin' -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP 2.x Quick How-to
Maybe as a first question - how 'done' do you consider the basic architecture of the CMP2.0 module? Done enough that there aren't going to be any major structural changes, or might it get turned upside down? As a frame of reference for my frame of mind, in my statements/questions below, I'm assuming that it _won't_ get turned upside down. Dain Sundstrom wrote: > > The query-method element is right out of the EJB 2.0 spec. The > element is similar to jaws finder element, except I have > broken the query element into from and where. Thank you. having them combined made some things really painful. This is something I was going to change in JAWS. > I also support order as jaws > did. The new code doesn't have the new pre-load logic, but I will add > something similar in phase 3, where I'll add ejb-ql support. Do you have any objection to Bill or I getting the initial underpinnings in there now? It's changed quite a bit since the version of JAWS that you (apparently) based your new work on. On a related (triggering, in fact) note: do you see your CMP implementation obsoleting JAWS, or augmenting it? Personally, I had intended on taking a chainsaw through JAWS anyway, so I wouldn't mind seeing it obsoleted. If it's obsoleted, I really think we may as well get more people than you working on it - hence the above question. Or if not, I'll find something else to do. > > If you find any bugs or would like to request a feature, please email me. I > will fix bugs as they are discovered, and feature req1uests I will > definitely think over. I really think that these should be posted on the sourceforge site - bugs because it lets us get more bandwidth - people other than you can fix the bugs, which means that more eyes will be on the code, which will lead to better code. That's why it's open source, after all. thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: The next generation GUI (was : Re: [JBoss-dev] EJX and XML)
Dain Sundstrom wrote: > I was just picking a fight :) > OK, I just discarded my rant-mail. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: >> > > So if we remove the passivation cache, do we loose commit Option A? If not, > how do we keep bean data alive while passivated? > > I still may not understand this. I think Mark is just suggesting losing the passivation part of the cache. The cache we keep, it just keeps growing and growing and growing. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: >>>I'm just curious what was the passivation cache for? >>> >>> >> >>Memory management. If your database contains 10 GB and you only have 1GB >>of memory, you'll need to swap out some bean based on some criteria (LRU >>by default) to make room. >> >> >>-danch >> >> > > Exactly, so what was the passivation cache? During passivation we want to > dump data to make room for new objects. I think I'm lost... Why would we > want to cache objects that we are tring to remove from memory? > > -dain It's a cache that passivates when it has over a certain number of object within it. It doesn't passivate what it's trying to cache, it passivates the overage. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
Rickard Öberg wrote: > On Mon, 25 Jun 2001, Rickard Öberg wrote: > >>AFAICT the only problem in integrating with Tomcat is the whole >>ClassLoader architecture. >> > > AFAIK no it isn't. That was nailed ages ago. Works great. Except that Jasper has different behavior when it compiles JSPs than when they're run. (the classes in ejb-jars in the ear are available at run time, but not when Jasper is compiling.) > > What doesn't work great is Tomcat. It's dead slow. Do some benchmarks and be > disturbed. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
Rickard Öberg wrote: >>yep, also for those that really want I believe the for pay add-on will be a >>killer... >> >>look who is still lurking :) >> >>hey kiddo, when you pull your head out of your arse and your coma, you can >>come and help us again, it is a shame to see so much talent go to waste... >>do you like what you hear on JB3.0? >> > > Well, the mgmt yadda yadda is nice 'n all, but the big problem is still > there: it'll run piss-poor with Tomcat. It doesn't really matter what fancy > stuff you can think up with that crap hanging around. > > There, I said it, it pisses me off. The J2EE stack is a dream but nothing > more unless Tomcat is fixed. > Which is why Jules has been busy getting Jetty working. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: >>|Will this affect commit Option A and B, which doesn't passivate? I'm >> >>not true. >> >>Even under option A if you are under heavy load, the cache can passivate >>under you. >> >> > > Good, I guessed from the code that passivation ment that we need to reload > the data after activation (i.e., bean data should not be keept, in the vm, > after a passivation). During passivation I de-referance the bean data. I'm > just curious what was the passivation cache for? > > -dain > Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: > I am about to commit an MBean / EJB pair whose only purpose in life is to > stress the cache locking logic. > > Because it is an MBean it never goes through the RMI layers and so we are > seeing RAW performance of the logic that does the thread mutex semaphore and > all taht... that was the part I had to optimize when I went to SUN... now > with the new logic 50 threads all pinging on 1 object. > > on my new athlon it crawls to an halt at 50 clients in parallel (they wait > 100ms before pinging again) and there is almost no invocation going > through... This is a good test because it shows worst case, but can it be called a realistic test? I'm only bringing this up because, well, if I saw somebody with an application designed such that every user had to share a single synchronized object, I'd say "well, yah, that'll perform fer shite!" > > :( > > anybody ELSE seen this? I am almost leaning towards TOTALLY removing the > passivating caches and associated mutex logic as is It does look like the behavior people have been complaining about. I'd not be in favor of permanently removing the passivating caches, however - making them non-default, sure, rewrite them absolutely, but they really have to be available for truly large installations. Truly large installations (running over N terabyte databases) will still need memory management. No that's not a typical installation, but don't you want to be able to support it? > > Ok I will say the word... this is shite ... > > or is it just me? > > marcf > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: > > as I said the simpler design is with "nopassivation" stuff in it. I believe > with gig ram machines floating around you can carefully design your > deployment so that you will never need passivation. > That's true for 99% of possible installations, but there will always be databases that won't fit into memory. Also, if you run a single VM on a 1GB linux box and try to give it that big a heap and have the number of users that that size implies, i suspect you'll have some mighty big threading and garbage collection issues with the current Tomcat/RMI implementations. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can Home references get stale?
taking a _quick_ look into the java.rmi.dgc package it looks like Remote
references (which your Home references now are - Right?) can indeed get
stale. the DGC ackage works on a lease basis, where each lease has a
certain duration. Not that I know what to do about it at this point.
-danch
Bill Burke wrote:
> We save a reference to our homes in a static variable in various classes
> so that we don't have to keep looking it up.
>
>
>
> --
>
> class SomeClass
>
> {
>
> public static MyBeanHome myBeanHome = null;
>
>
>
> public void init()
>
> {
>
> InitialContext ctx = new InitialContext();
>
> myBeanHome = (MyBeanHome)ctx.lookup("MyBean");
>
>
>
> }
>
> }
>
> --
>
>
>
> Jetty/JBoss(2.2.1) has been running for a few days now and we're getting
> the folloowing exception when we call a finder on SomeClass.myBeanHome
>
>
>
> java.rmi.MarshalException: Invalid remote object
> <>
>
> If we don't use myBeanHome and instead use one freshly looked up in the
> InitialContext, the finder works fine.
>
>
>
> BTW, we have set to False in standardjboss.xml so all
> parameters are RMIized. We've had our service running for more than a
> few days before and never got this problem, we used to have
> set to True. That's the only thing I can think that's different.
>
>
>
>
>
> Thanks,
>
>
>
> Bill
>
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS mysterious, at least for me...
Bill Burke wrote: > danch, > > If you need any help, send me an email, since I'm responsible for this. I > just thought that this was a new feature that I added and wouldn't be > allowed into 2.4. I was a bit unsure of that, too, but this is pretty important. Also, given that Dain has committed a 2.0 CMP implementation based on but sharing no code with JAWS, we may want to move our efforts over there for RabbitHole. > > Also, I can share the test writing load if you like. I'm feeling a little > guilty that I'm checkin in stuff that I'm not writing a JBoss-Test for, > although I have tested the changes against our application's test framework. > I already have generic test code for this - I just need to adapt it to use JUnit, and tighten it up a bit so that I can automate the process of telling whether it worked or not. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS mysterious, at least for me...
Lennart Petersson wrote: > Got the latest from branch 2.4 from CVS today and was looking for the newly >implemented read-ahead stuff. I see that not all things regarding this are >implemented in the 2.4 branch, some is in main branch. Look at >src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntityCommand.java as an example >where you can see that the latest contribution (findByPrimaryKey may now do a >read-ahead depending on configuration by Bill Burke) is made on the main branch and >not 2.4 branch. > I'll move the code from HEAD to the 2.4 branch over the next couple of days. I need to transition my tests into JBossTest to do this. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCFinderCommand.java
[EMAIL PROTECTED] wrote: > User: patriot1burke > Date: 01/06/21 14:57:22 > > Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc > JDBCFinderCommand.java > Log: > added constructor to facilitate re-use. Removed extra > login for setting up FinderResults since this class is really not used anymore. Bill, We need to talk a little bit here - my long term notion for the finderresults was to extend it into the invoker layers so that the collection that a client gets from these would be a proxy over the finder results. At that point we could add a 'page-size' parameter and a protocol between the client proxy and the server-side FinderResults to request that a new page of entities be brought into memory. This would allow us to support finders returning truly huge result sets without crashing out on memory. Naturally, this would really only be useful from batch processes for example (no matter how well we optimize, no user is going to sit while the software goes through 10 million rows!), so the real utility of it could easily be questioned. Would such a feature seem useful to you? Any others with opinions on the matter? thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Linux startup scripts
What goes wrong, though? [EMAIL PROTECTED] wrote: > Hello everybody, > > I found in the documentation a description on how to start and stop JBoss > on a linux machine with an rc.d script. I made this on my machine, but > JBoss is not starting up correctly (basically it is not starting at all). > Does anybody have an idea, on how the startup script will work correctly? > > Mit freundlichen Gruessen / best regards > > Markus M. May > > Think4You AG > Hanauer Landstrasse 135-137 > > 60314 Frankfurt / Main > > T. +49 69 2424 18 14 > F. +49 69 2424 18 60 > > mailto:[EMAIL PROTECTED] > http://www.think4you.com > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?
Isn't that B (I thought it was C that uncached and sent the impl back to the pool) Vincent Harcq wrote: > Hi, > > I am not expert at all in all these but,... > > In commit-option C, a EntityInstanceCache may exist and then the row > removed by an external system, so you have to read from db to be sure > the entity still exists. > > Vincent. > > > > -Message d'origine- > *De :* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]*De la part > de* Bill Burke > *Envoyé :* mardi 19 juin 2001 16:58 > *À :* Jboss-Development@Lists. Sourceforge. Net > *Objet :* [JBoss-dev] Is findByPrimaryKey optimized enough in > JAWS/CMP, even BMP? > > The reason I ask is that it seems all finders go straight to the > Persistence manager with no optimizations in front of it. Couldn't > "findByPrimaryKey" look in the EntityInstanceCache and avoid a DB, > "does exist", call? Is this as easy as modifying > org.jboss.ejb.EntityContainer.find(...) ?? You're safe if > "findByPrimaryKey" has been overrided by the Bean developer because > org.jboss.jeb.EntityContainer.setupHomeMapping will not map the > finder to EntityContainer.find, but rather to the Bean class. At > first glance, I can't find words stating that this optimization is > illegal, although the Object Interaction Diagram does show a call to > the database for ejbFind. Comments? > > > > Thanks, > > > > Bill > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is findByPrimaryKey optimized enough in JAWS/CMP, even BMP?
Bill Burke wrote: > The reason I ask is that it seems all finders go straight to the > Persistence manager with no optimizations in front of it. Couldn't > "findByPrimaryKey" look in the EntityInstanceCache and avoid a DB, "does > exist", call? Is this as easy as modifying > org.jboss.ejb.EntityContainer.find(...) ?? You're safe if > "findByPrimaryKey" has been overrided by the Bean developer because > org.jboss.jeb.EntityContainer.setupHomeMapping will not map the finder > to EntityContainer.find, but rather to the Bean class. I think this is the right place to do it - I wouldn't want the persistenceManager messing around in the cache (I had that at one point with the collection finder optimizations and it just increased system coupling with no performance advantage over what's there now (memory usage advantage, however)) > At first glance, > I can't find words stating that this optimization is illegal, although > the Object Interaction Diagram does show a call to the database for > ejbFind. Comments? > I don't see anything wrong with a cache look-aside before hitting the DB. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
Filip Hanik wrote: >>Sorry, it is a *very* clear need. And CVS just doesn't cut it. >> > > can't we, uhm you (I'm not a committer:), use some sort of tag which makes > CVS automatically insert the comment and audit info into the actual code > file? > I know this is doable with CVS > any thoughts? > Doing that you mostly get revision comments like "Changed a bunch of stuff: this should work now." Not quite what we had in mind. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] no select-for-update with finder optimization(read-ahead)
Bill Burke wrote: > This is just as simple as modifying the getSql method in > JDBCLoadEntitiesCommand, correct? > Should be. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
I think in this example, though, you're mixing paradigms too much. If
you want to write SQL in session beans, go ahead. If you want to use
entity beans as an object layer over the database, do that. You will
have to be very carefull in mixing them this way.
EJBs are intended to be an Java/OO technology - I'd expect
to do the summation in the Java space, not the SQL one.
Will that perform well enough? It depends on the sizes of your datasets
and how you define 'well enough'.
I think this is another case of the various trade-offs in the EJB spec -
Its a distributed object component technology, and dismays the RDB folks
sometimes, but a lot of it seems aimed so squarly at relational storage
on the backend that it bothers the OO purists at other times.
Imagine if the default behavior were for the ejb container to perform
store after every method call - people would flog the database to death
calling individual getters and setters! Adding an option to perform
ejbStore inline would need to have a fairly fine degree of granularity -
per method, I think.
David Esposito wrote:
> Here's an example to further illustrate why delayed ejbStore() is
> problematic.
>
> What about a situation where you keep a 'bucket' in a table to improve the
> performance of your application. For example, you keep a
> "current_account_balance" in your User table rather than doing a
> SUM(transaction_amount) on your Transactions table each time you need an
> account balance.
>
> In a Session Bean, I should be allowed to do something like the following
> (very roughly pseudocoded):
>
> TransactionBean t = transHome.findByPK(xxx);
>
> t.setTransactionAmount(765.99);
>
> DataSource ds = (DataSource)lookup("MyDS");
> Connection con = ds.getConnection();
> Statement stat = con.createStatement();
>
> ResultSet rs = stat.executeQuery("SELECT SUM(transaction_amount) AS total
> FROM Transactions WHERE user_id = 444");
>
> UserBean u = userHome.findByPK(444);
>
> u.setCurrentAccountBalance(rs.next().getFloat("total"));
>
>
> Something like that ... In the above case (i've tried it in several areas in
> my app), the SELECT() statement is still reading the old data because the
> Container hasn't written the changes out ... Of course, I MUST ensure that
> this happens in a transaction so that in case there is a problem, I don't
> end up with unsynchronized data ..
>
> (I use this example to point out that it's not just that ejbRemove happens
> immediately ... making ejbRemove delay as well would not fix the situation i
> just described)
>
> -Dave
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
David Esposito wrote: > > I am surprised that I am the only one that has raised this particular > example. It seems like it's something that people would do every day. > Actually it's far more common for people to complain about behavior closer to what you want - "Why is ejbStore being called so often?" when they access an entity directly from their client code. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] No storeEntity before ejbFind
Jay Walters wrote:
> You are still confused Gina, if you go into SQL*Plus and type the following
>
> create table foo ( x varchar(32));
> set autocommit off;
> insert into foo values ('gina');
> select * from foo;
>
> you will see the value just inserted and you are in the middle of the
> transaction. Rollback will clean out the table...
>
> This has always been (V4-V8i) and will always be... otherwise how would
> after triggers work for example.
Or RI?
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! I thought of suggesting that he put the 'setRecord' method into a RequiresNew transaction, but that would break his transactional semantics (and might deadlock him). I suppose he could just break the remove into a separate transaction, but logically, the code he has is exactly what makes sense as a single transaction. Jay Walters wrote: > He wants the update SQL to execute before the remove SQL? The commit isn't > the issue, it's the order of operations. > > What does the spec say about when remove() needs to execute the SQL? > > My question would be, if the bean has been removed should the persistence > manager still be trying to update it? I can understand that one might want > to somehow consider side effects, such as a database trigger so maybe one > can't optimize out the update. > > Cheers > > -Original Message- > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 15, 2001 12:38 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem > > > Why is this a serious problem? The weblogic docs for the flag you mention > indicate the commit is still not done until the end of the transaction and > that you would only notice this if your db allows for uncommitted reads. > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
The behavior you'd get by setting that flag to false in weblogic would also allow him to not break referential integrity in the case of his transaction. Scott M Stark wrote: > Why is this a serious problem? The weblogic docs for the flag you mention > indicate the commit is still not done until the end of the transaction and > that you would only notice this if your db allows for uncommitted reads. > > From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164 > Using delay-updates-until-end-of-tx to Change ejbStore() Behavior > > By default, WebLogic Server updates the persistent store of all beans in a >transaction only at the completion (commit) of the > transaction. This generally improves performance by avoiding unnecessary updates and >repeated calls to ejbStore(). > > If your datastore uses an isolation level of READ_UNCOMMITTED, you may want to allow >other database users to view the intermediate > results of in-progress transactions. In this case, the default WebLogic Server >behavior of updating the datastore only at > transaction completion may be unacceptable. > > You can disable the default behavior by using the delay-updates-until-end-of-tx >deployment element. When you set this element to > "false," WebLogic Server calls ejbStore() after each method call, rather than at the >conclusion of the transaction. > > Note: Setting delay-updates-until-end-of-tx to false does not cause database updates >to be "committed" to the database after each > method invoke; they are only sent to the database. Updates are committed or rolled >back in the database only at the conclusion of > the transaction. > > > > - Original Message - > From: "David Esposito" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, June 15, 2001 9:01 AM > Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem > > > >>Hello all, >> >>I have spent the past few hours reading up on other people with similar >>problems to mine. So I am familiar with what the EJB spec says (somewhat >>related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect to >>when a Bean is required to write its data out to persistent storage. >>However, this seems to be counterintuitive and is a serious problem for >>operations that manipulate multiple data sources. >> >> > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] soo... RMI-IIOP
I was doing some thinking on an IIOP invoker a while back. I would have spoken up before now, but I've got plenty to do with JAWS. (more below) Ole Husgaard wrote: > Hi, > > I probably won't find much time for helping > out with this, though it is a most interesting > project. > > marc fleury wrote: > >>ah yes then it is much more complicated since we need to have ANY client >>calling our stuff. >> > > Yes, a simple encapsulation of the method > invocation over IIOP is quick, but does not > ensure interoperability. I agree > > For interoperability we need to export real > CORBA objects, with no special encapsulation. > And that is somewhat more complicated. > > The paper Gerald Brose: "Reflection in CORBA, > Java and JacORB" might be helpful: > http://jacorb.inf.fu-berlin.de/~brose/papers/jit98.ps.gz > > But if possible, we should try not to depend > on any particular CORBA implementation. > > Maybe one day we will even generate stubs and > skeletons for IIOP on-the-fly, like Rickard > did with dynamic proxies for the JRMP transport. > However I would wait with that, even if it means > that an external IDL compiler would have to > be run at deployment time. > Actually, I was looking at the Dynamic Skeleton Interface - we should be able to use it to do without (compiled) skeletons on the server. > > >>BTW I will change the invocation layer as part of JBOSS3.0 but will take >>care of porting anything you have in there, let keep in touch. >> > > One thing that would be nice: The ability to > have several different transports for invoking > the same container. Multiple invokers for the container? I agree! > If designed in from the start, I don't think it > would complicate or slow down the invocation > code. > > > Best Regards, > > Ole Husgaard. > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Audit Trail Support
James Cook wrote: >>Really cool stuff! This can be easily implemented in CMP/JAWS since JAWS >>keeps the old state alive. >> >> > Bill, > > Before digging into source, can you answer these questions? We have a need > to identify which fields have changed in our state objects for an audit > trail. I am gathering information regarding the "tuned updates" process to > see if it will give us some direction: > > 1. How does JAWS keep old state alive? It shoves it (basically - details are more, um... detailed) into the Context on read and update. > 2. Does the mechanism assume that the request to persist an object comes > back to the same container that served the object? Yes. This will need to be re-evaluated when clustering comes into the picture. > > thanks, > jim > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ClassCastException: org.opentools.minerva.jdbc.xa.XAPoolDatasourc e
Cast to javax.sql.DataSource, not the XA DataSource. David Cao wrote: > Hi, > > I am trying to access a jdbc pool to MS SQL Server, but I got this problem > when I try to cast the ref into XADataSource, I can't find any document or > source about org.opentools.minerva.jdbc.xa.XAPoolDataSource, does any one > know this problem? > > Thanks a lot. > > David Cao > - Energizing by Thinking > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Bill Burke wrote: > Another possible bug related to this same problem. [please read below]. > > EntityInstanceInterceptor gets the mutex of the Entity's key before going > into the do..while loop. If a different thread/transaction rollsback, the > mutex gets detached from the EntityEnterpriseContext and the thread in the > do..while loop is acquiring a lock on a context that is not attached. Am I > missing something here? I don't think so. Do we need to mark the mutex as invalid? When we add teh wait/notify, invalidation should also notify. > > I'd really like to go in and fix this problem, but I really need another set > of eyeballs to make sure I'm doing things right. Danch, can you volunteer > to help? Also, while I'm in this code, maybe I should consider adding the > "Missing wait/notify" and remove that buggy do..while loop as well. > I can certainly review. I won't have much time for investigation until this evening, and then my wife may have other plans for my time. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
I don't understand what is different between the two. Are you saying to
have only one place where we wait? If so I agree.
Bill Burke wrote:
> It's not this same. Basically you have a loop to check to see if the
> transaction has been commited or unlocked, but you put a wait of 5 seconds
> in there. After the 5 seconds if you're still not locked loop again.
>
> OT, how does transaction timeout destroy the thread? TIA.
>
>
> Bill
>
>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of danch
>>(Dan Christopherson)
>>Sent: Wednesday, June 06, 2001 3:35 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
>>READ-ONLY Beans)
>>
>>
>>I think that's roughly equivalent to Georg's 'wait(DEADLOCKTIMEOUT +
>>1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
>>
>>Bill Burke wrote:
>>
>>
>>>I remember Marc talking about this issue awhile back. He said the best
>>>performance would be to have the wait within a loop with a 5
>>>
>>second wait.
>>
>>>while (!locked()) // pseudo code
>>>{
>>> this.wait(5000);
>>> if (!locked())
>>> {
>>> log.("LOCKING-WAITING");
>>> }
>>>}
>>>
>>>
>>>Regards,
>>>Bill
>>>
>>>
>>>
>>>
>>>
>>>>-Original Message-
>>>>From: [EMAIL PROTECTED]
>>>>[mailto:[EMAIL PROTECTED]]On Behalf Of danch
>>>>(Dan Christopherson)
>>>>Sent: Wednesday, June 06, 2001 1:31 PM
>>>>To: [EMAIL PROTECTED]
>>>>Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
>>>>READ-ONLY Beans)
>>>>
>>>>
>>>>danch (Dan Christopherson) wrote:
>>>>
>>>>
>>>>
>>>>>Georg Rehfeld wrote:
>>>>>
>>>>>
>>>>>
>>>>>One problem here is that when we're waiting on the context, we want to
>>>>>wait on the context (i.e. "ctx.wait(DEADLOCKTIMEOUT + 1000)")
>>>>>
>>>>>
>>>>Just doing
>>>>
>>>>
>>>>>wait and notifyAll on the interceptor itself will involve all calls on
>>>>>our entity when we just want to handle contention for the one context.
>>>>>
>>>>>The other problem is that if we're waiting on the transaction, we don't
>>>>>want to do wait/notify on the context - I don't know what we do want to
>>>>>wait on, but we really need to know when the transaction ends.
>>>>>
>>>>>
>>>>Actually, looking closer at the code, it's probably the mutex that we
>>>>want to wait on in both cases - it is specific to the key involved.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>___
>>>Jboss-development mailing list
>>>[EMAIL PROTECTED]
>>>http://lists.sourceforge.net/lists/listinfo/jboss-development
>>>
>>>
>>
>>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: [JBoss-dev] Fast Updates Based on Row ID
Just for the record, I don't mind having Oracle specific optimizations in JAWS, it's just that the current structure of JAWS does not really lend itself to this. Also, if you do use Oracle specific stuff for this optimization, the option in a jaws entity should be given a name that will tell users clearly that it won't work on other databases. K.V. Vinay Menon wrote: > Well, > We are an Oracle shop and woudl benefit [like loads of other Oracle > users] from these changes. Remember they are there as an option. If you > choose not to use them JAWS will work as usual. > > Vinay > - Original Message - > From: "Jay Walters" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 06, 2001 6:18 PM > Subject: RE: [JBoss-dev] Fast Updates Based on Row ID > > > >>This is oracle specific as far as I know (insert...returning...). The >>create problem needs to be addressed if one cannot retrieve the rowid, the >>logic needs to check and see if rowid is set or not - maybe Vinay already >>did this, I didn't look that hard. >> Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Not stupidity! these are complex issues, which is why the listserv is getting such a flogging on this topic. Bill Burke wrote: > Please excuse my stupidity! > > Bill > > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
I think that's roughly equivalent to Georg's 'wait(DEADLOCKTIMEOUT +
1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
Bill Burke wrote:
> I remember Marc talking about this issue awhile back. He said the best
> performance would be to have the wait within a loop with a 5 second wait.
>
> while (!locked()) // pseudo code
> {
>this.wait(5000);
>if (!locked())
>{
> log.("LOCKING-WAITING");
>}
> }
>
>
> Regards,
> Bill
>
>
>
>
>>-----Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of danch
>>(Dan Christopherson)
>>Sent: Wednesday, June 06, 2001 1:31 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
>>READ-ONLY Beans)
>>
>>
>>danch (Dan Christopherson) wrote:
>>
>>
>>>Georg Rehfeld wrote:
>>>
>>>
>>>
>>>One problem here is that when we're waiting on the context, we want to
>>>wait on the context (i.e. "ctx.wait(DEADLOCKTIMEOUT + 1000)")
>>>
>>Just doing
>>
>>>wait and notifyAll on the interceptor itself will involve all calls on
>>>our entity when we just want to handle contention for the one context.
>>>
>>>The other problem is that if we're waiting on the transaction, we don't
>>>want to do wait/notify on the context - I don't know what we do want to
>>>wait on, but we really need to know when the transaction ends.
>>>
>>
>>Actually, looking closer at the code, it's probably the mutex that we
>>want to wait on in both cases - it is specific to the key involved.
>>
>>
>>
>>
>>
>>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
Georg Rehfeld wrote: > Hi Dan, > > me: > >>>I still would insist on the correction of the missing wait/notify >>>issue, as I still believe that the extremly bad response times >>>under load are more caused by several threads executing tight >>>loops consuming most of the cpu time instead of simply waiting >>>and let the cpu to JBoss doing real work! >>> > > you: > >>It certainly can't help! >> > > Did you really mean it can NOT help? If so, could you explain? > But, as you have had a closer look, I consider it a typo. I meant that spinning the wheels like that can't be helping performance. Your suggested change would just about have to help. > > >>Actually, looking closer at the code, it's probably the mutex that we >>want to wait on in both cases - it is specific to the key involved. >> > > Is key here <==> Entity Beans PK, then it sounds promising! It's equivalent. I believe it's actuall a CacheKey (from org.jboss.util) which wraps the bean's PK to protect JBoss from badly implemented keys (hashCode and equals) > Does 'looking closer' mean, you are about to actually code it? > Which would be very nice, I still havn't seen much of the JBoss > code and are not at all the expert, as everybody can see from > the several errors I made in my attempt, waiting on the wrong > object, notifyAll instead of notify and still beeing confused > where to put the notify. > > regards > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Bill Burke wrote: > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of Georg >>Rehfeld >>Sent: Wednesday, June 06, 2001 1:11 PM >>To: [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans >> >> >>Hello Bill, hi all, >> >> >>>- What's wrong with doing a Context lock, but not doing a transactional >>> >>lock >> >>>for read-only beans? If you do this you'll still be spec compliant, >>>correct? How would this affect your performance results? I'm >>> >>pretty sure >> >>>the spec says it's up to the Container developer to decide how to synch >>>beans per transaction, but you are required to make EntityBeans single >>>threaded. >>> >>It was reported, that trying to access the beans concurrently without >>TX and with non-reentrant beans leads to very similar LOCKING-WAITING >>behaviour as within a TX. >> >>But if you access outside a TX AND have the bean reentrant there >>is no LOCKING-WAITING anymore without any change to existing >>code. I don't think, this reentrnce really is a problem, data >>gotten outside a TX must be considered inconsistent anyway, so >>why not let hundreds of clients do getters concurrently, where is >>the problem? >> >>Concurrent access from clients accessing inside different TXs is >>still serialized, the only potential danger with reentrant is, >>when DIFFERENT clients having THE SAME TX access the bean >>concurrently, how should this normally be possible (except for the >>allowed callback case)? >> >>Before modifying code that makes JBoss incompliant, why not simply >>use existing spec conform features, it's all there, just use it! >> >> >>>- All in all, IMHO, Transactional EntityBean locking should be removed >>>totally from JBoss. This locking is totally useless when you have more >>> >>than >> >>>one instance of JBoss hitting the sam DB anyways. Let the DB handle the >>>locking. If you want your EntityBeans synched across >>> >>transactions use the >> >>>select-for-update options if you're using CMP, or with BMP, >>> >>manage the DB >> >>>locks yourself. >>> >>Oh, but then you cannot use commit option A anymore. So for A the >>serialization IS required, and with B and C someone has to implement >>multiple instances of the bean before removing the locking at >>container level. >> >> > > Why do you have to implement multiple instances of the bean? For a quick > fix, just take out the code that waits for the EntityBean to leave the > transaction in EntityInstanceInterceptor. Leave the locking code that comes > after the transaction waiting stuff, it's used to make the bean > single-threaded(correct?). This will still work for commit-option 'A' won't > it? If you keep the bean single-threaded, option 'A' is not violated. > What about this scenario: == Transaction A Transaction B Lock Entity B Context Wait for entity b context. Call into business method Modify data Unlock Entity B Context Lock entity B Context Read data A Modified Rollback! = Now transaction B has read data that has never been modified. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
danch (Dan Christopherson) wrote: > Georg Rehfeld wrote: > > > > One problem here is that when we're waiting on the context, we want to > wait on the context (i.e. "ctx.wait(DEADLOCKTIMEOUT + 1000)") Just doing > wait and notifyAll on the interceptor itself will involve all calls on > our entity when we just want to handle contention for the one context. > > The other problem is that if we're waiting on the transaction, we don't > want to do wait/notify on the context - I don't know what we do want to > wait on, but we really need to know when the transaction ends. Actually, looking closer at the code, it's probably the mutex that we want to wait on in both cases - it is specific to the key involved. Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Fast Updates Based on Row ID
Will the 'returning into ?' work in databases other than oracle? If not, that would be a problem: until JAWS is chainsawed (refactored to separate SQL syntax from the Command hierarchy), it'll be difficult to manage DB specific stuff at that level. Vinay's original patch isn't too bad, because it doesn't cause us to generate syntax that won't work elsewhere (you could give the name of a normal column as the rowid column and it would work (so long as that column is unique)) Jay Walters wrote: > Use "insert ... returning rowid into ?" > > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 06, 2001 12:02 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Fast Updates Based on Row ID > > > Hi, > > I may be wrong about oracle rowid changing on row update, it's been a > couple of years. However interbase/firebird dbkey definitely does change > on update, and I think someone mentioned the sql server analogue does too. > > In this situation, it seems to me that commit option A cannot be used, > since to get a valid rowid, you have to read the db within the same > transaction you are updating in. > > Also, even in Oracle, how can this be used with a newly inserted bean? > > create --inserts row in db > > later in same transaction, change values on this bean, the generated save > has no rowid unless you fetched it in perhaps ejbpostcreate??? If you can > fix this one, perhaps it can also be used to fetch values supplied by > triggers on insert, such as sequence/generators used for abstract id. > > Am I wrong here? Could you explain in detail how this will work? > > Thanks > david jencks > > On 2001.06.06 10:50:53 -0400 K.V. Vinay Menon wrote: > >>The ROW ID bit does not touch ANY other portion in the JBoss source >>except >>for >> >>a) Generating SQLs >>b) Setting parameters. >> >>Options A,B and C should work as usual, correct me if I am wrong. As for >>option D, I am suprised that it has become part of our 'standard' commit >>options. I wrote some code and never had a chance to commit it and unless >>someone else has commited stuff for option D let me know and I'll have to >>commit the code! >> >>Vinay >>- Original Message - >>From: "David Jencks" <[EMAIL PROTECTED]> >>To: <[EMAIL PROTECTED]> >>Sent: Wednesday, June 06, 2001 2:40 PM >>Subject: Re: [JBoss-dev] Fast Updates Based on Row ID >> >> >> >>>Hi, >>> >>>This looks very interesting. I'm kind of too lazy to read your code to >>>find out the answer for myself... >>> >>>My impression is that Oracle ROWID and similar facilities such as >>>Interbase/firebird dbkey are stable only within a transaction, and in >>> >>fact >> >>>expected to change with any update. Could you please explain how your >>> >>new >> >>>feature guarantees updating the correct row with commit options A, B, >>> >>C, >> >>>and D? >>> >>>Thanks >>>david jencks >>> >>> >>>On 2001.06.06 08:56:02 -0400 K.V. Vinay Menon wrote: >>> Hi Marc, When you were here in London we'd discussed adding functionality >>to >> use things like ROWID for fast updates and deletes [as opposed to >>using >> primary keys]. I have been able to implement this by 1. Adding a field in jaws.xml called rowid-column name. This is ROWID >>for >> Oracle and can be something else for other databases. If you do not >>want >> to use this feature just don't specify the tag and it will use the default mechansm based on the primary key. >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>http://lists.sourceforge.net/lists/listinfo/jboss-development >>> >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>http://lists.sourceforge.net/lists/listinfo/jboss-development >> >> > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
Georg Rehfeld wrote:
> I still would insist on the correction of the missing wait/notify
> issue, as I still believe that the extremly bad response times
> under load are more caused by several threads executing tight
> loops consuming most of the cpu time instead of simply waiting
> and let the cpu to JBoss doing real work!
It certainly can't help!
>
> I'm NOT a multithreading expert though. My first thought was to
> simply insert a wait() directly after the two
> Logger.debug("LOCKING-WAITING ..."); calls and a notifyAll()
> after the ctx.unlock() in the finally clause, but I've 2 problems
> with this approach:
>
> 1. there is a mutex.aquire()/mutex.release() pair; when I simply
> would wait inbetween, I think no other thread can enter the code
> thus rendering EntityInstanceInterceptor dead, when one thread is
> waiting, on the other hand, I can't simply release the mutex
> there, it's a critical section. A solution would be to have a
> wait directly before the } while (ctx == null); if ctx == 0 as of
> this (hand made) context diff:
>
> catch (InterruptedException ignored) {}
> finally
> {
> mutex.release();
> }
> + if (ctx == null) {
> + // let the thread that has the lock proceed
> + // at same time let's detect possible deadlock
> + long start = System.getCurrentTimeMillis();
> + try {
> + wait(DEADLOCKTIMEOUT + 1000);
> + }
> + catch (InterruptedException ignored) {}
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. "ctx.wait(DEADLOCKTIMEOUT + 1000)") Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity when we just want to handle contention for the one context.
The other problem is that if we're waiting on the transaction, we don't
want to do wait/notify on the context - I don't know what we do want to
wait on, but we really need to know when the transaction ends.
Also, I'd do a notify, not a notifyAll - why schedule every thread to
run when only one will be able to run anyway?
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Bill Burke wrote: > - What's wrong with doing a Context lock, but not doing a transactional lock > for read-only beans? won't you still block on the context lock? > If you do this you'll still be spec compliant, > correct? How would this affect your performance results? I'm pretty sure > the spec says it's up to the Container developer to decide how to synch > beans per transaction, but you are required to make EntityBeans single > threaded. > > - Which xml file has the flag (isReadOptimized)? IMHO, if this read-only > thing is accepted, this flag for it should be in jboss.xml, not jaws.xml, so > that BMP developers have access to it. I agree, if it's there at all. > > - All in all, IMHO, Transactional EntityBean locking should be removed > totally from JBoss. This locking is totally useless when you have more than > one instance of JBoss hitting the sam DB anyways. Let the DB handle the > locking. If you want your EntityBeans synched across transactions use the > select-for-update options if you're using CMP, or with BMP, manage the DB > locks yourself. Being able to specify the transaction isolation level for your CMP beans would also let us control concurrent access better. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
It may well be usefull, but does this behavior belong in the normal EntityInstanceInterceptor? Why not just implement an non-blocking variant of EntityInstanceInterceptor, and reconfigure your stack in jboss.xml? K.V. Vinay Menon wrote: > OK! > I know that it is kind of controversial and that its spec violation and > stuff but why can't we have multi threaded beans for read-only cases? Why > should we be bothered about transactions? We don't lock the database for > selects do we? Non-purists who face real world performance issues - please > let me know if these is complete rubbish or is something that 'could' prove > useful.. unless someone voluteers to write the code for multiple bean > instances per home handle! > > > Vinay Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] New problems in JAWS?
Scott M Stark wrote:
> But your change works fine in the 2.2.2 codebase as I ran the same testsuite
> against it before making the release and I reran it today and it does not show
> the same errors. Is there a difference in the code comitted to the 2.2.2 branch
> versus main?
Thank you. I was afraid I had a paper bag problem on my hands!
On the other hand, it gets curiouser and curioser: The stack trace you
posted earlier indicates that JAWS is trying to put something into a
java.util.Collection for some reason. Better trace output from jaws is
in order (like which column was it?).
>
> The tests typically run against the DefaultDS which is Hypersonic. This is certainly
> true of the simple bank example which is failing. Here is its jaws.xml file:
>
>
>
>
> java:/DefaultDS
> Hypersonic SQL
>
>
> Account
> Account
> true
> false
> false
> false
> 300
>
> id
> id
> VARCHAR(256)
> VARCHAR
>
>
> balance
> balance
> REAL
> REAL
>
>
> findLargeAccounts
> balance > {0}
> balance
>
>
>
> Customer
> Customer
> true
> false
> false
> true
> 600
>
> name
> name
> VARCHAR(256)
> VARCHAR
>
>
> id
> id
> VARCHAR(256)
> VARCHAR
>
>
>
>
>
>
> - Original Message -
> From: "danch (Dan Christopherson)" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 01, 2001 9:42 AM
> Subject: Re: [JBoss-dev] New problems in JAWS?
>
>
>
>>This is probably (almost without a doubt) related to the change I
>>committed recently. What database are you running the tests against?
>>
>>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: [JBoss-dev] Re: [jboss-board] "I want to help JBoss!"
Sreeram, If you can look at this, it's probably related to some "instanceof MarshalledObject" checking that I just added. This is probably leading us into the wrong bit of logic somewhere. This _might_ also be dependent somewhat on the database you're running against - This code doesn't like postgres at all, while i've been told it works against Oracle. I'll be looking at this later, as well, so if you do dig into it keep in touch. thanks, Danch Scott M Stark wrote: > Start by tracking down the current tracking down the current cmp errors > seen in the bank module of the jbosstest suite. There's nothing like > jumping into the deep end off of the high dive from the start. > > - Original Message - > From: "K S Sreeram" <[EMAIL PROTECTED]> > To: "Juha Lindfors" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, June 01, 2001 8:37 AM > Subject: [JBoss-dev] Re: [jboss-board] "I want to help JBoss!" > > > >>I have reasonable experience with database related programming. I would love >>to help in the jboss-cmp engine, but i have no idea where to begin.. perhaps >>you or somebody else can guide me on where to begin regarding the jboss-cmp >>engine >> >>Regards >>KS >> >>On Friday 01 June 2001 22:02, you wrote: >> >>>Hi, >>> >>>I suggest you subscribe to the mailing lists and follow the current >>>development there (especially jboss-dev), pick up what's happening in the >>>discussions and follow the CVS logs. Then when you feel comfortable try >>>development by writing a patch to fix a bug, etc. and gradually move from >>>that to more demanding development. >>> >>>If you have extensive database knowledge, our CMP engine needs help. Also, >>>if writing is your thing, we desperately need people to keep the manuals up >>>to date with the releases. >>> >>> >>>http://www.jboss.org/business/lists.html >>> >>>regards, >>> >>>-- Juha >>> >>>At 20:31 1.6.2001 +0530, you wrote: >>> Hi I am experienced java and j2ee developer, and i am very interested in contributing to the JBoss project. I have used jboss as the j2ee application server for my company's projects. Regards KS To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>http://lists.sourceforge.net/lists/listinfo/jboss-development >> >> > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] New problems in JAWS?
This is probably (almost without a doubt) related to the change I committed recently. What database are you running the tests against? Scott M Stark wrote: > I have rerun the jbosstest suite and I am also seeing errors on tests that worked a > couple of days ago. Most of the new errors are complaints about not being able to > load a ResultSet column due to an EOFException like that shown below. The >corresponding > server log exception follows and shows the problem occuring in the JAWS layer. > It you have comitted a change to JAWS recently please check it against the jbosstest >suite. > org.jboss.test.bank.interfaces.BankException: Could not get account for >bank/Customer:Customer:5678.991382748487/Marc, > Cause:org.jboss.test.bank.interfaces.BankException: Could not create account, >Cause:java.rmi.ServerException: Transaction rolled > back; nested exception is: > javax.transaction.TransactionRolledbackException: Load failed; nested >exception is: > java.sql.SQLException: Unable to load a ResultSet column into a variable of >type 'java.util.Collection': > java.io.StreamCorruptedException: Caught EOFException while reading the stream >header; nested exception is: > java.rmi.ServerException: Load failed; nested exception is: > java.sql.SQLException: Unable to load a ResultSet column into a variable of >type 'java.util.Collection': > java.io.StreamCorruptedException: Caught EOFException while reading the stream header > at >sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245) > at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122) > at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invoke(Unknown >Source) > at >org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:357) > at >org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123) > at $Proxy5.getAccount(Unknown Source) > at org.jboss.test.bank.test.Main.testMultiThread(Main.java:158) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:155) > at junit.framework.TestCase.runBare(TestCase.java:129) > at junit.framework.TestResult$1.protect(TestResult.java:100) > at junit.framework.TestResult.runProtected(TestResult.java:117) > at junit.framework.TestResult.run(TestResult.java:103) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.run(TestSuite.java:144) > at >org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) > at >org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) > > [JAWS] java.sql.SQLException: Unable to load a ResultSet column into a variable of >type 'java.util.Collection': > java.io.StreamCorruptedException: Caught EOFException while reading the stream >header[JAWS] at > >org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getResultObject(JDBCCommand.java:487)[JAWS] > at > >org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getResultObject(JDBCCommand.java:503)[JAWS] > at > >org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.loadOneEntity(JDBCLoadEntityCommand.java:146)[JAWS] > at > >org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.handleResult(JDBCLoadEntityCommand.java:131)[JAWS] > at > >org.jboss.ejb.plugins.jaws.jdbc.JDBCQueryCommand.executeStatementAndHandleResult(JDBCQueryCommand.java:59)[JAWS] > at > org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCCommand.java:160)[JAWS] >at > >org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:102)[JAWS] > at > >org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.loadEntity(JAWSPersistenceManager.java:156)[JAWS] > at > >org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:371)[JAWS] > at > >org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:220)[JAWS] > at > >org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:186)[JAWS] > at > org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)[JAWS] >at > >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:298)[JAWS] > at > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)[JAWS] at > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:190)[JAWS] > at > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)[JAWS] at > org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323)[JAWS] at > >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:480) > > > > > ___ > Jboss-development mailing
Re: [JBoss-dev] Compiling error
Are you trying to build with jdk1.2.2? If so, you'll need the optional RMI/IIOP package to get those classes. Better still, upgrade to jdk1.3 Jordi Piñol wrote: > Hi, > When I compile my application, not found javax.rmi.* and > javax.rmi.PortableRemoteObject. > I use the next jars: /client/ejb.jar. > Which jar has this classes ? > > -- > ·· > Jordi Pinyol Essi Projects > Ingeniero de Desarrollo > [EMAIL PROTECTED]t +34 977 221 182 > http://www.essiprojects.com f +34 977 230 170 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] minerva-1_0b3.jar missed in JBoss 2.3 beta?
Minerva has been forked. JBoss (2.3 or later) now uses JBoss-pool, source for which is in CVS at sourceforge. Darius Davidavicius wrote: > After i compiled last source code of Jboss server i have found minerva-1_0b3.jar is >missed in dist/lib/ext > > If it is removed? What is replacment for it? if for Jboss 2.1 i was getting >oraclePoll like: > > name="DefaultDomain:service=XADataSource,name=oraclePool"> > oraclePool > name="DataSourceClass">org.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl > > > > Thanks for reply in advance, > Darius D > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] overlapping of ejb components in naming context
Stephan Gruschke wrote: > Hi, > > > If I deploy two ejb components named ejb/foo and ejb/foo/fooBar in > jboss I get a class cast exception ($Proxy) while rebinding the > components. You have two things with the same name - the component (ejb/foo) and the context (ejb/foo, which must be created to hold the fooBar component). Think of this as a filesystem. > > Is this allowed to have directories and component names in the same > jndi lookup folder? The problem is that you've given them the same name - would any other directory let you have a file named 'foo' and a directory named 'foo' in the same directory? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Paul Hammond wrote: >>From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, May 15, 2001 10:47 AM >>To: [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] Avoiding big numbers of selects loading EJB >>cache >> >> >> >>>If the cache is empty on startup, and you have a finder method returning >>>say 5000 objects, then that will generate 5000 individual selects to the >>>database, not very efficient. I have seen a third party trading system >>>done using BMP >>>on WebLogic whereby initially they have to load up a portfolio of >>>100,000 trades to run a Risk report on them. Takes about 30 minutes plus >>>to start it up. Not nice. >>> >> >>Reporting off of EJBs is probably not the best implementation choice at >>this point in specdom - you'll be much kinder on your servers if you >>report the old fashioned way. >> > > I know what you're saying, but you want to deal with objects rather than > data, and encode most business logic on the EJB server so it's accessible to > all rather than have it in stored procedures (if that's what you mean by the > old fashioned way?). There are also lots of other session beans to do with P > & L, and booking a trade and all the rest all using the same data so you > would get cross benefits having it in the cache. Reports would be running > concurrently with all of this. How sophisticated are the reports? I see a lot of reports that don't really have any logic about them, other than grouping, summing, etc - the things that relational databases have been tuned to do well. If there is logic beyond what standard SQL queries can do, I think you are correct that that should be in a bean somewhere. You might consider writing stateless session beans issuing SQL directly, bypassing the entity layer, if the logic isn't used elsewhere. Not the purist approach, certainly, but I'm personnally willing to get dirty to get things to work acceptably. > > It's just that EJB is a bit lacking at the moment in that area like you say, > however, with CMP making headway, it should hopefully get to a stage whereby > BMP for the most part is just not necessary, that is certainly highly > desirable as far as I'm concerned. I'm all for EJBQL, I think that too much > developer time is spent on EJB systems worrying about persistence because of > the limitations to date of CMP. True. > > Do you mean JDO for data access objects? No, I just ment any abstraction that would give you a separate persistence layer beneath your beans. This would be a good place to hook up that read-ahead cache. (a second level cache) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Sorry to cause confusion by being imprecise. Your post was correct, it's ejbFindByXXX elbLoad (* N) if the beans are uncached or if commit option B or C and the beans have not yet been loaded in the current transaction. Note that commit option B or C and calling the finder from a client with CMT can be (N * M) + 1, where M is the number of methods called! If all N objects are in cache, and commit option is A, there will be only 1 hit to the database. -danch Jay Walters wrote: > Maybe I understand less than I think. Are you all saying that the actual > scenario is > > ejbFindByXXX > ejbFindByPrimaryKey > ejbLoad > > when the bean needs to be loaded from disk (2N+1) and > > ejbFindByXXX > ejbFindByPrimaryKey > > (N+1) when the N objects are all already in the app servers cache? > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Paul Hammond wrote: > Hi guys, > > > > Just new to this list and JBoss. > > > > My question centers around efficient loading of EJBs into JBoss's EJB cache. > > > > Normally if you have a finder method, findByXXXYYYZZZ etc, which returns > an Enumeration > > of the EJBs in question, you have a corresponding ejbFindByXXXYYYZZZ > method that returns > > an Enumeration of primary key objects for that particular EJB. > > > > My understanding is that the implementation of the findByXXXYYYZZZ > method by the container will generally call findByPrimaryKey with the > Primary key objects that are returned by ejbFindByXXXYYYZZ one by one to > load each EJB if it's not already in the cache. This typically involves > an individual select statement from the database etc for each EJB to be > loaded. Actually it can get even worse than that: the container's findByXXXYYYZZZ probably won't even call findByPrimaryKey itself, but will allow that to be deferred until such time as the bean is actually accessed. This is a more elegant implementation, since the bean will always have to be checked to see if its state needs loading - avoiding findByPrimaryKey in findByXXXYYYZZZ keeps the load and check in one place. Also, remember that the cache needs to be checked in there as well! > > If the cache is empty on startup, and you have a finder method returning > say 5000 objects, then that will generate 5000 individual selects to the > database, not very efficient. I have seen a third party trading system > done using BMP > on WebLogic whereby initially they have to load up a portfolio of > 100,000 trades to run a Risk report on them. Takes about 30 minutes plus > to start it up. Not nice. Reporting off of EJBs is probably not the best implementation choice at this point in specdom - you'll be much kinder on your servers if you report the old fashioned way. But yes, this will be very ugly with BMP, no matter what app server you're using. > > Really what you want is one select statement to get all the relevant > information. How do you fit that into the EJB container architecture though? With BMP, you can only cheat. With CMP, the CMP engine can do it. > > > I know O/R tools like TopLink can integrate with say WebLogic so that > WebLogic uses TopLink as it's cache. TopLink does support I believe > instantion of lots of objects with one query. So you can in effect > quickly load the cache. Therefore the container will find all the > objects for the primary key are already in the cache and won't call > findByPrimaryKey, at least that is my understanding of it, please > correct me if I'm wrong here. > I'm not sure, but I think it's more likely that WebLogic + TopLink wind up with a two level cache. > > Now in relation to JBoss, and leaving aside JAWS for a moment because > supposing I want to use BMP, how would I do this with JBoss if I didn't > want to use a third party O/R tool. You don't want to break the > container contract obviously but I can't see how you would avoid doing > what the container would do. > > > Here's the sequence of events I would see happening in this hypothetical > ejbFindByXXX method > > > > Method findByXXX called. > > Delegated to ejbFindByXXX > > Select query to database. > > Iterate through results set. > > Get the primary key from each row > > Check if it's in the cache. > > If it is not, create a new EJB and populate it from the result set and > insert it into the cache This you really can't do. The container must be allowed to control the lifecycle of EJB instances. > > Regardless, add the EJB primary key to the enumeration > > Return the enumeration > > > Now the container generated method would do pretty much the same thing, > but will always find the EJB in the cache because we've put it there, > and hence will never call findByPrimaryKey and generate loads o > > select statements. > > > > However we would be messing with the containers cache which is > completely outside the contract > > and we would be duplicating what the container does ourselves, so it's > not a satisfactory way of doing > > things. > > > Is there a legit way of doing this, or is it simply not possible to > avoid all those calls to findByPrimaryKey and the associated select statements. See the 'fat-key' pattern on theserverside.com. WARNING: this may significantly degrade JBoss' cache performance! Do you use data access objects? If so, consider creating a static 'read-ahead buffer' in the data access object for a particular entity. Use weak references for the objects, and the PK for the key. in ejbFindByPrimaryKey, check the read ahead before executing SQL. > > Would JAWS CMP do it efficiently? It will. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Sacha Labourey wrote: > Hello, > > > > There is currently a JAWS RFE on this particular topic. > And I'm working on it. This is taking longer than I'd expected because doing it right is going to effect more of JBoss than i'd anticipated (and more than I'd really like) A couple days more and I should have at least a patch for people to flame me on. > > > And if you want to use this in BMP, I think there is a pattern proposed > on theserverside. Having dug through all this code, I believe that the 'fat key' pattern will work in JBoss. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] bug???
This looks like a bug to me, too, but it's a tomcat bug, not a JBoss bug. Go to the Tomcat site at jakarta.apache.org Sng Wee Jim wrote: > Hi, > I'm using JBoss-2.2.1 with Tomcat-3.2.1 integrated. > > doesn't work in JSP as > expected, instead > org.apache.jasper.compiler.ParseException was thrown by JBoss. > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
