Well, let's presume you have a single app server, and the number of pooled connections to the DB that are available is 20(max). If any of your TX's hang(may happen in an untested/new system), you lose a connection for 600 sec (10 min.). If you get a very mild DOS attack, you're left hanging out in the wild for ten minutes. So it depends on a lot of stuff. Being pragmatic calls for consistency... Note to the rest of the team that you're using a "quick and dirty" fix and set up a short End Of Life for the "feature", then replace it(quickly) for something better. Overall and from my own experience, no optimization ever makes up for bad architecture, so I humbly advise you to try to face this problem at an architectural level.
On the other hand, if you aren't compressing/decompressing inside a transaction (another no TX SLSB facading the rest?) then there would be no need, apparently, to raise the timeout in the server. Here are some ideas: If the information is a lot of records, it is almost sure going to be used at chunks or pages. Transmit only a few chunks at first (say, a page and the two next) then a chunk when the user scrolls. Always keep the already loaded chunks in memory/disk so if the user backtracks you don't have to make an extra round trip to the server. This is often referred to as JIT retrieval of records. If the records have some fields that are very large but not always used, don't send them over the wire unless they are needed. You can do this modifying a little bit your VOs. This is usually referred to as lazy loading of fields. These solutions are (at least from the info you provided) orthogonal to using compression/decompression. And they will probably scale and perform a bit better, while providing you a lot of control over the situation and the optimizations that should/shouldn't be applied on a case by case basis. My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: SAMINATHAN [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 16, 2002 4:57 PM > To: Juan Pablo Lorandi; [EMAIL PROTECTED] > Subject: Re: Re: Compression API in EJB > > > Hi > > Yup, that is what i wanted to do. > > Basiclly my client is not starting any transaction. > All the transaction is getting started from my SLSB. > I don't have any intention to do compressing > /decompressing inside the bean. > > > Will i face any problem, if i set my transaction timed out > to 600 sec in my app server ? > > Thanks and Regards > Saminathan. > > > ----- Original Message ----- > From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 16, 2002 8:13 PM > Subject: Re: Compression API in EJB > > > > I didn't mean compression as a quick and dirty solution per > se; In the > > light of what Saminathan has told me, it seems like a quick > and dirty > > workaround. I've tried a similar approach before, that is > compression > > as a quick and dirty patch (End Of Life: 2 weeks) for enhancing > > network trips and wasn't comfortable with the results, because (de) > > compressing large amounts of data within a TX was only possible by > > augmenting the transaction timeout of my server(TXs were wrongly > > terminated when the timeout elapsed), which decreased overall > > performance greatly. Perhaps I chose wrong (or too few) words to > > explain my view. Compression does have a place in my > practice (as do > > "quick and dirty" solutions; that one bought me 2 weeks dev > time ;-) > > ). Saminathan, if you're going to be using compression, try to keep > > compressing/decompressing decoupled from TX EJBs. > > > > My 2c, > > > > Juan Pablo Lorandi > > Chief Software Architect > > Code Foundry Ltd. > > [EMAIL PROTECTED] > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > Mobile: +353-86-2157900 > > www.codefoundry.com > > > > > > > -----Original Message----- > > > From: A mailing list for Enterprise JavaBeans development > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Richard S.Martin > > > Sent: Tuesday, April 16, 2002 2:51 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Compression API in EJB > > > > > > > > > I disagree that compression is a "quick and dirty" solution. > > > Obviously it depends on the particular requirements fo the > > > application, but in many situations it is highly > appropriate. If the > > > requirement is for large amounts of data (obviuously "large" is > > > releative here) and especially where the application > developer has > > > no control over the speed of the connection (e.g the internet), > > > compression can be an excellent solution. > > > > > > Compression/decompression essentially moves the > performance problem > > > from being outside the developers control (i.e. network > throughput) > > > to inside the developers control (overhead of > > > compressing/decompressing). When the problem is in the latter > > > domain, it can be adressed through the familiar means of > scaling an > > > enterprise application. > > > > > > Of course, as Juan pointed out, it is important to be > sure that your > > > application really does require this approach. > > > > > > Richard Martin > > > > > > On Tuesday 16 April 2002 07:02 am, Juan Pablo Lorandi wrote: > > > > Ok, now the compression does make sense. > > > > > > > > Still, I would suggest you focus on a better way to > > > communicate than > > > > compression/decompression (the quick and dirty > solution); perhaps > > > > a Web Service; something that loads information on the > client JIT > > > > and minimizes round trips will provide much better performance > > > > than the compression/decompression, as it will add a lot of > > > > latency > > > to network > > > > trips, BOTH ways. > > > > > > > > I can't remember any bibliography on the subject that > > > applies directly > > > > to J2EE (but I can remember a lot of MS DNA/.NET papers on the > > > > subject). Take a look around at www.theserverside.com > (I hope it's > > > > still there... I've been out of circulation for 6 months or > > > > so...), hopefully you will find more on the subject. > > > > > > > > HTH, > > > > > > > > Juan Pablo Lorandi > > > > Chief Software Architect > > > > Code Foundry Ltd. > > > > [EMAIL PROTECTED] > > > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > > Mobile: +353-86-2157900 > > > > www.codefoundry.com > > > > > > > > > -----Original Message----- > > > > > From: SAMINATHAN [mailto:[EMAIL PROTECTED]] > > > > > Sent: Tuesday, April 16, 2002 5:31 AM > > > > > To: Juan Pablo Lorandi > > > > > Subject: Re: Compression API in EJB > > > > > > > > > > > > > > > Am sorry for not telling about my client. > > > > > It is not web client.It is a swing client with JTable. It is > > > > > stand alone application. > > > > > > > > > > We have web and palm client also but that not a problem.The > > > > > major work is going to be done by Swing client. > > > > > > > > > > It is never going to cross more than 1 MB. > > > > > > > > > > Thanks and Regards > > > > > Saminathan. > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> > > > > > To: "'SAMINATHAN'" <[EMAIL PROTECTED]> > > > > > Sent: Tuesday, April 16, 2002 9:59 AM > > > > > Subject: RE: Compression API in EJB > > > > > > > > > > > OK, by the look of your web site, seems like it could > > > be heavy... > > > > > > > > > > > > How heavy? Say, 10 MB per record or so? Or are they > MANY SMALL > > > > > > records? > > > > > > > > > > > > Just curious, > > > > > > > > > > > > Juan Pablo Lorandi > > > > > > Chief Software Architect > > > > > > Code Foundry Ltd. > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > > > > Mobile: +353-86-2157900 > > > > > > www.codefoundry.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: A mailing list for Enterprise JavaBeans development > > > > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of SAMINATHAN > > > > > > > Sent: Tuesday, April 16, 2002 5:01 AM > > > > > > > To: [EMAIL PROTECTED] > > > > > > > Subject: Re: Compression API in EJB > > > > > > > > > > > > > > > > > > > > > The data here is very heavy.And we are using EJB1.1. > > > > > > > > > > > > > > And our SLSB is a facade. > > > > > > > > > > > > > > Thanks and Regards > > > > > > > Saminathan. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "David Jones" <[EMAIL PROTECTED]> > > > > > > > To: <[EMAIL PROTECTED]> > > > > > > > Sent: Monday, April 15, 2002 10:21 PM > > > > > > > Subject: Re: Compression API in EJB > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Reading through this thread I am also unsure > why you are > > > > > > > > compressing/uncompressing your data. In your > > > example the data > > > > > > > > is used to populate a form. It is therefore > > > unlikely that we > > > > > > > > are talking about a lot of data here (or am I > > > wrong?). Also I > > > > > > > > imagine your client and app server have a good > connection > > > > > > > > between them. > > > > > > > > > > > > > > > > If therefore the approach is to limit the amount of > > > data sent > > > > > > > > over the wire I would suggest looking at the > > > > > > > > > > > > > > classic Session > > > > > > > > > > > > > > > Facade pattern and EJB local interfaces as better > > > > > > > > solutions. > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > --- Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote: > > > > > > > > > Why compress anything? What does it accomplish? > > > > > > > > > > > > > > > > > > How is it an object stream? Do you mean an > > > > > > > > > java.io.ObjectOutputStream ? If that's the case, just > > > > > > > > > > > > > > make sure the > > > > > > > > > > > > > > > > stream goes into a holder that is > > > > > > > > > either Serializable or a primitive (for instance use > > > > > > > > > java.io.ByteArrayOutputStream, then extract the > > > byte array). > > > > > > > > > Check the java docs for implications and > considerations > > > > > > > > > about it (interface is java.io.Serializable). > > > Also check out > > > > > > > > > the RMI > > > > > > > > > documentation. > > > > > > > > > > > > > > > > > > By all means comment on why you want to compress an > > > > > > > > > > entity, and > > > > > > > > > > > > > > then decompress it on the client (which, I'm > > > presuming, will > > > > > > > > > benefit from a superb network connection to the > > > App Server). > > > > > > > > > Based on data I have, I > > > > > > > > > think it'll negatively impact on performance. The > > > > > > > > > rationale behind the design choice has me intrigued. > > > > > > > > > > > > > > > > > > Also, I'm posting this directly to EJB-INTEREST as I > > > > > > > > > > think the > > > > > > > > > > > > > > other post didn't make it to the list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juan Pablo Lorandi > > > > > > > > > Chief Software Architect > > > > > > > > > Code Foundry Ltd. > > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > > > > > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > > > > > > > Mobile: +353-86-2157900 > > > > > > > > > www.codefoundry.com <http://www.codefoundry.com/> > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: SAMINATHAN [mailto:[EMAIL PROTECTED]] > > > > > > > > > Sent: Monday, April 15, 2002 2:42 PM > > > > > > > > > To: Juan Pablo Lorandi > > > > > > > > > Subject: Re: Compression API in EJB > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok Sir, Let me explain further > > > > > > > > > > > > > > > > > > My client never has an access directly to the DAO.It > > > > > > > > > > should go > > > > > > > > > > > > > > thru minimum my SLSB. > > > > > > > > > > > > > > > > > > When i loading a form with the user requested > record,i > > > > > > > > > just need to get the data from ejbLoad(). Since it is > > > > > > > > > bean managed am providing the value object to my > > > > > > > > > ejbLoad() from my DAO. > > > > > > > > > > > > > > > > > > (My value object will contain collection of > > > > > > > > > > ect( > > > > > > > > > > > > basically it is > > > > > > > > > > > > > > > > parent -- child )) > > > > > > > > > > > > > > > > > > What i wanted to do is compress my value object > > > and pass thru > > > > > > > > > the bean layer. > > > > > > > > > > > > > > > > > > This i can only do on the form load, cause > there is no > > > > > > > > > business logic or operation involved in that. > > > > > > > > > > > > > > > > > > But in other case my beans are going to use my value > > > > > > > > > > object in > > > > > > > > > > > > > > that i don't want to do any jugglery. > > > > > > > > > > > > > > > > > > Now i have one question sir, i compressed my > object now > > > > > > > > > it > > > > > > > > > > > has become a object stream , > > > > > > > > > do i need to send my object as a stream? > > > > > > > > > > > > > > > > > > bye > > > > > > > > > saminathan > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: Juan <mailto:[EMAIL PROTECTED]> > Pablo Lorandi > > > > > > > > > To: 'SAMINATHAN' <mailto:[EMAIL PROTECTED]> > > > > > > > > > Sent: Monday, April 15, 2002 6:52 PM > > > > > > > > > Subject: RE: Compression API in EJB > > > > > > > > > > > > > > > > > > Yes, it's YOUR data. Even if you're using CMP > EBs, you > > > > > > > > > can > > > > > > > > > > > still compress your data, assuming you also > decompress > > > > > > > > > it > > > > > > > > > > accordingly. > > > > > > > > > > > > > > BUT, > > > > > > > > > > > > > > > > > > 1) You will lose search capabilities in the > Persistance > > > > > > > > > layer (a SQL query won't support compression) > > > > > > > > > 2) Performance gains depend on the network (latency, > > > > > > > > > > bandwidth, > > > > > > > > > > > > > > availability) between the different parts of your > > > > > > > > > > application. > > > > > > > > > > > > > > On most applications this isn't generally true. > > > Performance > > > > > > > > > gains are simply the > > > > > > > > > difference between compression/decompression time vs. > > > > > > > > > network conditions > > > > > > > > > > and round-trips. It's impossible to even guess the > > > > > > > > > > > > > > scenario from the > > > > > > > > > data you provide. > > > > > > > > > 3) Your diagram seems to implicate the client has > > > > > > > > > > direct access > > > > > > > > > > > > > > to the DAO, thru the use of value objects. > Why the EJBs > > > > > > > > > then? > > > > > > > > > > > > > > > > > > Perhaps if you could explain more.... > > > > > > > > > > > > > > > > > > > > > > > > > > > Juan Pablo Lorandi > > > > > > > > > Chief Software Architect > > > > > > > > > Code Foundry Ltd. > > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > > > > > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > > > > > > > Mobile: +353-86-2157900 > > > > > > > > > www.codefoundry.com <http://www.codefoundry.com/> > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: A mailing list for Enterprise JavaBeans > > > > > > > > > development > [mailto:[EMAIL PROTECTED]] On Behalf > > > > > > > > > Of SAMINATHAN > > > > > > > > > Sent: Monday, April 15, 2002 10:36 AM > > > > > > > > > To: [EMAIL PROTECTED] > > > > > > > > > Subject: Compression API in EJB > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > I would like to know whether compression > of object > > > > > > > > > in EJB is allowed or not.Though am not > directly going > > > > > > > > > to use > > > > > > > > > > > inside the bean. > > > > > > > > > > > > > > > > > > For example i have the follwoing architecture > > > > > > > > > > > > > > > > > > Client -----> SLSB -----> EB -----DAO -----DB > > > > > > > > > > > > > > > > > > |--------------------->VALUE OBJECT > > > > > > > > > > > > > > > > > > on Form load my ejbSelect will return me the value > > > > > > > > > > > > > > object.Since in > > > > > > > > > > > > > > > > my case it is a BMP my DAO's select method > > > > > > > > > will return me the value object and i want to > compress > > > > > > > > > that before sending to entity --- Session > and in the > > > > > > > > > client code i will decompress and use it.Note am not > > > > > > > > > doing any compression in my bean. > > > > > > > > > > > > > > > > > > And by doing this , will my performance and response > > > > > > > > > time > > > > > > > > > > > improve? > > > > > > > > > > > > > > > > > > Is there any known or unknown implication there in > > > > > > > > > this? > > > > > > > > > > > > > > > > > > Thanks and Regards > > > > > > > > > Saminathan. > > > > > > > > > > > > > > > > ===== > > > > > > > > David J. Jones, <[EMAIL PROTECTED]>, > > > > > > > > Virgin Mobile USA, > > > > > > > > 8th Floor, > > > > > > > > 22 Fourth Street, > > > > > > > > San Francisco, > > > > > > > > CA, 94103, Work: 415 932 5470. > > > > > > > > USA. Fax: 415 358 4999. > > > > > > > > > > > > > > > > __________________________________________________ > > > > > > > > Do You Yahoo!? > > > > > > > > Yahoo! Tax Center - online filing with TurboTax > > > > > > > > http://taxes.yahoo.com/ > > > > > > > > > > > > > > > ============================================================ > > > > > > > == > > > > > > > ============= > > > > > > > > > > > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and > > > > > > > > > > > > > > include in the > > > > > > > body > > > > > > > > > > > > > > > of the message "signoff EJB-INTEREST". For > general help, > > > > > > > > > > > > > > send email > > > > > > > > > > > > > > > to [EMAIL PROTECTED] and include in the body of > > > the message > > > > > > > > "help". > > > > > > > > > > > > > > > ============================================================ > > > > > > > == > > > > > > > ============= > > > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and > > > > > > > include in the body of the message "signoff > EJB-INTEREST". For > > > > > > > > > general help, send email to [EMAIL PROTECTED] and > > > > > > > include in the body of the message "help". > > > > > > > > > > > ============================================================== > > > ============= > > > > To unsubscribe, send email to [EMAIL PROTECTED] and > > > include in the body > > > > of the message "signoff EJB-INTEREST". For general help, > > > send email to > > > > [EMAIL PROTECTED] and include in the body of the message > > > > "help". > > > > > > ============================================================== > > > ================ > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity > to whom they > > > are addressed. All information is the view of the > individual and not > > > necessarily the company. If you are not the intended > recipient you > > > are hereby notified that any dissemination, distribution, > or copying > > > of this communication and its attachments is strictly > prohibited. If > > > you have received this email in error please notify: > > > [EMAIL PROTECTED] > > > > > > > > > ============================================================== > > > ================ > > > > > > ============================================================== > > > ============= > > > To unsubscribe, send email to [EMAIL PROTECTED] and > include in > > > the body of the message "signoff EJB-INTEREST". For general help, > > > send email to > > > [EMAIL PROTECTED] and include in the body of the > message "help". > > > > > > > > ============================================================== > ============= > > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the > body > > of the message "signoff EJB-INTEREST". For general help, > send email > > to [EMAIL PROTECTED] and include in the body of the message > > "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
