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".
