Re: Serializer- and Deserializer-objects multi-threaded?

[Brian J. Sayatovic]

Title: Nachricht

As Tony points out, you could use a sort of Object Pool to hand out SimeplDateFormat insatnces to your deserializer instances as the factory constructs them, and devise a scheme to return them to the pool when the deserializer is no longer needed. You could also make a wrapper around SimpleDateFormat that is synchronized so as to be thread safe. IIRC, the problem with SimpleDateFormat was that they have a Calendar member variable in the class.  This is not used to maintain state, btu just to avoid re-creating a Calendar instance in each SimpleDateFormat method call that might need a Calendar.  For the longest time, the lack of thread safety was a porblem.  Recently, they "fixed" this by simply documenting it in the JavaDocs. I would urge you to consider writing your won custom date formatter/parser.  Assumign you have a specific textual representation of dates you'll be working with, it should be tedious but straight forward.  Thsi would give you the needed thread safety without the overhead of synchronization or the complexity of managing a pool. Regards, Brian. Martin Heitz wrote: Hi,   thanks for your answers. The reason for asking this is, that I have (de)serializers for a composed type which does not have a default constructor. So I need (as far as I understand the concept) at least a deserializer for rebuilding the object. One of the attributes of the object has the type dateTime, so I have a SimpleDateFormat to parse this. Sorrowly the SimpleDateFormat is quite expensive to create, so I do not want to create one for each parse process, but have a SimpleDateFormat class member in the deserializer to reuse it. Now the second "but": But the SimpleDateFormat is not thread-safe, it rarely occurrs that a runtime exception is thrown or that dates are not formatted correctly. If the deserializer is not used by multiple threads simultaneously I do not have an issue here, but if it is shred I run into trouble.'   If - as Brian J. Sayatovic writes - Axis gets a new instance each time from the factories my idea of improving performance by having a SimpleDateFormat as class mebmber does not help anyway :-(   Best regards from sunny Black Forrest, Germany,    Mattin    -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 14, 2004 12:26 PM To: [EMAIL PROTECTED] Subject: Re: Serializer- and Deserializer-objects multi-threaded? I've never seen any reference to threads in descriptions of serializers and deserializers (Axis 1.1). Certainly, the BeanSerializer has no special code for handling multiple threads, that I can see. It looks as though a new serializer/deserializer is created, from the factory, each time a type needs to be processed in the message. In any case, I can't quite see why you'd want to store state between calls to the serializer or deserializer, or store state in the de/serializer whilst processing a call. Tony "Martin Heitz" <[EMAIL PROTECTED]> wrote on 14/12/2004 10:55:38: > Hi, > > short question: Are Axis Serializer- and Deserializer-objects shared by > multiple threads (do they need to be thread-safe)? > > My question relates to Axis 1.1, but (because upgrading to a newer > release is always something one may not get out of sight) I am also > interested in an answer for Axis 1.2. > > Best regards from Black Forrest, Germany, > > Martin Heitz > Distributed Network Accounting Team > > Elsag Solutions AG > Roggenbachstr. 1 > D-78050 Villingen-Schwenningen > Germany > http://www.elsag-solutions.com > Tel: +49-(0)7721-9175-595 > Fax: +49-(0)7721-9175-800 >   >