Hi Gordon,
I changed the snapshot version of TopLink as suggested by you. I had to
modify the following classes;
IdentityHashtable, especially the static inner class Entry
TopLinkProperties
UnitOfWorkImpl
PropertiesHandler
and added the ReferenceMode enum.
The behavior is configurable in the persistence.xml with the following
property:
<property name="toplink.transactional.cache.mode" value="weak|hard"/>
Default is "hard" - so TopLink will behave as expected (with hard refs).
The "weak" setting causes the usage of weak references inside the
IdentityHashtables (actually in the static class Entry).
I used the toplink configuration infrastructure to achieve this. How I
can contribute the code back (I used the CVS and the maven build
system)? Could you please review my changes?
Btw. the TopLink code is clean, well documented and clear...
Thank you in advance, and Happy New Year 2008.
I attached the modified classes as well.
regards,
adam
Gordon Yorke schrieb:
> Hello Adam,
> What version of TopLink Essentials are you using now? There
> should be no problem getting this functionality into V3 but the V2
> patch branch is in restricted mode with only "approved" patches being
> checked in.
> -- Gordon
>
> Adam Bien wrote:
>> Gordon,
>>
>> thank you again for the fast answer. I have the issue not only in one
>> project, but in every project with object oriented persistence and
>> data binding. Not only rich clients, but JSFs/EJB3 apps are affected
>> as well.
>>
>> All the projects are commercial - so maintainability is an issue. If
>> I would implement this functionality into TopLink, is there any
>> chance to merge it into the trunk/head? Otherwise my customer
>> wouldn't accept my "private" hack :-) .
>>
>> Only then it would be interesting to my customer. However I'm sure
>> this would be really interesting feature not only for Rich
>> applications, but for JSF applications with Stateful Session Beans
>> and Extended Entity Manager as well.
>> JSF/EJB3 applications have the same issue - because you can keep all
>> objects persistent between transactions. Actually only domain objects
>> which are bound to the UI are interesting, all others could be GCed.
>> Hard references would hold all objects in memory - until the session
>> removal.
>>
>> thanks && regards,
>>
>> adam
>> Gordon Yorke schrieb:
>>> Hello Adam,
>>> I can appreciate the usefulness of what you are requesting but
>>> there is no means by which the provider can guarantee predictable
>>> behaviour. The onus would be on the application developer to ensure
>>> that the application forcefully keep the required objects from being
>>> garbage collected and that no dependency was place on the garbage
>>> collection for making objects un-managed (the transaction would
>>> still have to complete successfully even if the garbage collector
>>> was disabled).
>>> I could see this functionality being added as an advanced feature
>>> for users with specific needs but we would need to be careful in
>>> presenting this feature without due warnings.
>>> If you would like to attempt to produce this functionality within
>>> TopLink I would recommend that you update the UnitOfWork's
>>> collections "cloneMapping", "clonesToOriginals",
>>> "newObjectsCloneToOriginal", "newObjectsOriginalToClone" and
>>> "deletedObjects" to have weak references used within the collections
>>> when a weak identity map is set on the UnitOfWork. Perhaps have the
>>> member variables initialized to Maps that use only weak references.
>>> If you have any questions on the internals of the UnitOfWork and its
>>> place within the TopLink architecture I would be happy to help.
>>> --Gordon
>>>
>>> Adam Bien wrote:
>>>> Hi Gordon,
>>>> Gordon Yorke schrieb:
>>>>> "even if the object is no longer referenced by the application" ->
>>>>> why
>>>>> this? In case an object isn't referenced by the application any
>>>>> more, it
>>>>> could simply disappear... Especially in an unmanaged environment.
>>>>> This
>>>>> extension would be really valuable for rich clients ("rias").
>>>>> Actually
>>>>> this problem will have every rich client application. How hard
>>>>> would it
>>>>> be to provide a switch to be able to choose between hard and weak
>>>>> references?"
>>>>>
>>>>> Adam,
>>>>> Having changed objects disappear from the PersistenceContext
>>>>> based on weak references would be unpredictable. The application
>>>>> would have no way of knowing what changes would be written out and
>>>>> which ones would have been thrown away because of garbage
>>>>> collection. In your case perhaps the application is structured in
>>>>> such a way that only objects referenced by the application have
>>>>> the potential to be changed but in many applications that is not
>>>>> the case.
>>>> The approach with weak L1 cache should actually work for every
>>>> application managed entity manager, which is not shared between
>>>> threads and transactions.
>>>> This is the case in most RCP (Netbeans, Eclipse) applications,
>>>> where the Entity Manager is executed inside the same JVM as the
>>>> presentation tier.
>>>>
>>>>> Particularly in service based applications the changes could be
>>>>> applied through the merge() api without a reference ever existing
>>>>> from the application to the managed entity.
>>>>>
>>>> Absolutely. In service based applications you are right. Merge
>>>> would be the option then. However in real service based application
>>>> I would even use DTOs :-) . However we are working with a rich
>>>> domain model
>>>>> Having a GUI use the merge() api to have only the changed
>>>>> objects registered within the PersistenceContext and processed for
>>>>> changes is a much more effecient and scalable architecture.
>>>> Yes. In our case it would be a huge disadvantage. Until now we can
>>>> rely on the transparent persistence - which is great. Be forced to
>>>> detach the objects and invoke "merge" isn't a elegant solution.
>>>>> The complexity of the object model should not hamper the use of
>>>>> the merge() api as the GUI's update events could merge the root of
>>>>> the tree of Entities being changed and TopLink, with correct
>>>>> cascade merge settings, would handle the rest.
>>>>>
>>>> We have many UIs, Use Cases, reports etc. So there are many root
>>>> objects in place. This makes your suggested approach more difficult...
>>>>
>>>> regards -
>>>>
>>>> adam
>>>>> --Gordon
>>>>>
>>>>> -----Original Message-----
>>>>> From: Adam Bien [mailto:abien_at_adam-bien.com]
>>>>> Sent: Monday, November 19, 2007 5:08 PM
>>>>> To: persistence_at_glassfish.dev.java.net
>>>>> Subject: Re: Configuration of Client vs. Shared Cache
>>>>>
>>>>>
>>>>> Hello Gordon,
>>>>>
>>>>> thank you for the fast answer.
>>>>> Gordon Yorke schrieb:
>>>>>
>>>>>> Hello Adam,
>>>>>> An application managed EntityManager always wraps an Extended
>>>>>> Persistence Context. An Extended Persistence Context is not
>>>>>> released until the EntityManager is closed unlike a transactional
>>>>>> Container Managed Entity Manager which releases the Persistence
>>>>>> Context at the end of each transaction.
>>>>>>
>>>>>> If you need you can simulate the transactional EntityManager by
>>>>>> calling flush(), clear() before each commit() but this would
>>>>>> still leave you with the detached issue.
>>>>>>
>>>>>>
>>>>> This is our issue. Detached entities are a real problem in more
>>>>> complex
>>>>> applications...
>>>>>
>>>>>> The problem with holding the objects in a weak reference is the
>>>>>> change detection requirement of the PersistenceContext. Any
>>>>>> object touched by the PersistenceContext must be tracked by the
>>>>>> PersistenceContext and any changes to that object must be written
>>>>>> to the database on request, even if the object is no longer
>>>>>> referenced by the application. With weak references unwritten
>>>>>> changes could potentially be lost.
>>>>>>
>>>>>>
>>>>> "even if the object is no longer referenced by the application" ->
>>>>> why
>>>>> this? In case an object isn't referenced by the application any
>>>>> more, it
>>>>> could simply disappear... Especially in an unmanaged environment.
>>>>> This
>>>>> extension would be really valuable for rich clients ("rias").
>>>>> Actually
>>>>> this problem will have every rich client application. How hard
>>>>> would it
>>>>> be to provide a switch to be able to choose between hard and weak
>>>>> references?
>>>>>
>>>>>> There a multiple ways you could manage the volume of object
>>>>>> registered within a Persistence Context. On screen changes you
>>>>>> could close and create a new EntityManager but my recomended
>>>>>> approach would be to detach the display objects from the managed
>>>>>> objects. No need to create seperate classes but you could use
>>>>>> the merge facility of the EntityManager to merge the objects from
>>>>>> the GUI to the PersistenceContext for any object updates or
>>>>>> specific save events from the GUI.
>>>>>>
>>>>> The problem here: the object graph is really complicated with
>>>>> recursive
>>>>> algorithms (about 700 entities...). Therefore we would rely on
>>>>> "transparent persistence". Actually it works great with TopLink on
>>>>> Smalltalk :-) . We have only the issue in Java... However TopLink
>>>>> is the
>>>>> only OR-framework, which can handle this complexity. The only
>>>>> issue are
>>>>> the "hard" references.
>>>>>
>>>>>
>>>>>> This would limit the number of objects in your PersistenceContext
>>>>>> and mostlikly provide for a performance improvement from your
>>>>>> current design as less objects are being checked for changes. I
>>>>>> would also recommend that if you took this approach that you
>>>>>> switch the shared cache to be a softcache weak identity map.
>>>>>>
>>>>>>
>>>>> We switched the shared cache already. The L1-cache is our problem...
>>>>>
>>>>> thank you for the detailed answer,
>>>>>
>>>>> adam
>>>>>
>>>>>> --Gordon
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Adam Bien [mailto:abien_at_adam-bien.com]
>>>>>> Sent: Monday, November 19, 2007 11:46 AM
>>>>>> To: gordon.yorke_at_oracle.com
>>>>>> Cc: persistence_at_glassfish.dev.java.net
>>>>>> Subject: Re: Configuration of Client vs. Shared Cache
>>>>>>
>>>>>>
>>>>>> Hi Gordon,
>>>>>>
>>>>>> thank you very much for the fast reply. I'm thinking of the
>>>>>> Persistence
>>>>>> Context as an Identity HashMap, which primary goal is to keep the
>>>>>> consistency of the entities in a transaction.
>>>>>> However in our application (it is a rich client, which connects
>>>>>> directly
>>>>>> to the database without an application server or middleware), it
>>>>>> seems
>>>>>> like once loaded objects are hold
>>>>>> by the EntityManager until the method clear is invoked or the Entity
>>>>>> Manager is closed (we are using the current build - TopLink
>>>>>> v2b58). The
>>>>>> Entity Manager remains open between the transactions - it is even
>>>>>> not
>>>>>> cleared. We would like to work with the entities, without loading
>>>>>> them
>>>>>> from the database every time.
>>>>>>
>>>>>> We are using data binding between the domain objects and the UI - so
>>>>>> clearing the entity manager makes the entities detached (and
>>>>>> makes the
>>>>>> GC run) - the whole app has to be refreshed then. This in turn is
>>>>>> not
>>>>>> wished by the end users :-) .
>>>>>>
>>>>>> I'm wondering, whether it would be possible to hold the objects
>>>>>> using
>>>>>> weak-reference in the L1 cache / transactional cache. Then all
>>>>>> unneeded
>>>>>> objects would be automatically garbage collected. The
>>>>>> object-identity
>>>>>> would be still provided with this setting... Now the memory
>>>>>> consumption
>>>>>> increases - until Out Of Memory occurs...
>>>>>>
>>>>>> any thoughts?
>>>>>>
>>>>>> thank you in advance,
>>>>>>
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> adam
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gordon Yorke schrieb:
>>>>>>
>>>>>>
>>>>>>> Hello Adam,
>>>>>>> You may be confusing the Persistence Context with a cache?
>>>>>>> Sometimes the UnitOfWork which is the implementation of the
>>>>>>> Persistence Context in TopLink is described as a cache to
>>>>>>> explain some
>>>>>>> of its behaviours but its behaviour is beyond that of a cache.
>>>>>>> Because the Unit0fWork must track all objects that were ever read
>>>>>>> through or registered by the UnitOfWork to full its behavioural
>>>>>>> requirements the TopLink cache settings do not apply.
>>>>>>> --Gordon
>>>>>>>
>>>>>>>
>>>>>>> Adam Bien wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> TopLink cache consists of two parts:
>>>>>>>> 1. Client/L1
>>>>>>>> 2. Shared/L2
>>>>>>>>
>>>>>>>> Is it possible to configure them independently? In the TopLink
>>>>>>>> reference there are two sections:
>>>>>>>>
>>>>>>>> http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#BABGDJBC
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It seems like the @Cache annotation addresses the Client/L1 cache.
>>>>>>>> The properties (
>>>>>>>>
>>>>>>>> eg. <property name="toplink.cache.type.Order" value="Full"/>)
>>>>>>>> the L2.
>>>>>>>>
>>>>>>>> Is it possible to configure both caches using the persistence.xml
>>>>>>>> properties?
>>>>>>>>
>>>>>>>> I would like to configure Weak Caches for both levels, however it
>>>>>>>> seems like the L1 cache is still "Full" (or it uses "hard"
>>>>>>>> references
>>>>>>>> to entities)
>>>>>>>>
>>>>>>>> thank you in advance!,
>>>>>>>>
>>>>>>>> adam bien
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Consultant, Author, Java Champion
>>>>>>
>>>>>> Homepage: www.adam-bien.com
>>>>>> Weblog: blog.adam-bien.com
>>>>>> eMail: abien_at_adam-bien.com
>>>>>> Mobile: 0049(0)170 280 3144
>>>>>>
>>>>>> Books: Enterprise Architekturen (ISBN: 393504299X),
>>>>>> Java EE 5 Architekturen (ISBN: 3939084247),
>>>>>> J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and
>>>>>> Struts
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Consultant, Author, Java Champion
>>>>>
>>>>> Homepage: www.adam-bien.com
>>>>> Weblog: blog.adam-bien.com
>>>>> eMail: abien_at_adam-bien.com
>>>>> Mobile: 0049(0)170 280 3144
>>>>>
>>>>> Books: Enterprise Architekturen (ISBN: 393504299X),
>>>>> Java EE 5 Architekturen (ISBN: 3939084247),
>>>>> J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and
>>>>> Struts
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
--
Consultant, Author, Java Champion
Homepage: www.adam-bien.com
Weblog: blog.adam-bien.com
eMail: abien_at_adam-bien.com
Mobile: 0049(0)170 280 3144
Books: Enterprise Architekturen (ISBN: 393504299X),
Java EE 5 Architekturen (ISBN: 3939084247),
J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts
Gordon Yorke schrieb:
> Hello Adam,
> I can appreciate the usefulness of what you are requesting but
> there is no means by which the provider can guarantee predictable
> behaviour. The onus would be on the application developer to ensure
> that the application forcefully keep the required objects from being
> garbage collected and that no dependency was place on the garbage
> collection for making objects un-managed (the transaction would still
> have to complete successfully even if the garbage collector was
> disabled).
> I could see this functionality being added as an advanced feature
> for users with specific needs but we would need to be careful in
> presenting this feature without due warnings.
> If you would like to attempt to produce this functionality within
> TopLink I would recommend that you update the UnitOfWork's collections
> "cloneMapping", "clonesToOriginals", "newObjectsCloneToOriginal",
> "newObjectsOriginalToClone" and "deletedObjects" to have weak
> references used within the collections when a weak identity map is set
> on the UnitOfWork. Perhaps have the member variables initialized to
> Maps that use only weak references. If you have any questions on the
> internals of the UnitOfWork and its place within the TopLink
> architecture I would be happy to help.
> --Gordon
>
> Adam Bien wrote:
>> Hi Gordon,
>> Gordon Yorke schrieb:
>>> "even if the object is no longer referenced by the application" -> why
>>> this? In case an object isn't referenced by the application any
>>> more, it
>>> could simply disappear... Especially in an unmanaged environment. This
>>> extension would be really valuable for rich clients ("rias"). Actually
>>> this problem will have every rich client application. How hard would it
>>> be to provide a switch to be able to choose between hard and weak
>>> references?"
>>>
>>> Adam,
>>> Having changed objects disappear from the PersistenceContext
>>> based on weak references would be unpredictable. The application
>>> would have no way of knowing what changes would be written out and
>>> which ones would have been thrown away because of garbage
>>> collection. In your case perhaps the application is structured in
>>> such a way that only objects referenced by the application have the
>>> potential to be changed but in many applications that is not the case.
>> The approach with weak L1 cache should actually work for every
>> application managed entity manager, which is not shared between
>> threads and transactions.
>> This is the case in most RCP (Netbeans, Eclipse) applications, where
>> the Entity Manager is executed inside the same JVM as the
>> presentation tier.
>>
>>> Particularly in service based applications the changes could be
>>> applied through the merge() api without a reference ever existing
>>> from the application to the managed entity.
>>>
>> Absolutely. In service based applications you are right. Merge would
>> be the option then. However in real service based application I would
>> even use DTOs :-). However we are working with a rich domain model
>>> Having a GUI use the merge() api to have only the changed
>>> objects registered within the PersistenceContext and processed for
>>> changes is a much more effecient and scalable architecture.
>> Yes. In our case it would be a huge disadvantage. Until now we can
>> rely on the transparent persistence - which is great. Be forced to
>> detach the objects and invoke "merge" isn't a elegant solution.
>>> The complexity of the object model should not hamper the use of the
>>> merge() api as the GUI's update events could merge the root of the
>>> tree of Entities being changed and TopLink, with correct cascade
>>> merge settings, would handle the rest.
>>>
>> We have many UIs, Use Cases, reports etc. So there are many root
>> objects in place. This makes your suggested approach more difficult...
>>
>> regards -
>>
>> adam
>>> --Gordon
>>>
>>> -----Original Message-----
>>> From: Adam Bien [mailto:abien_at_adam-bien.com]
>>> Sent: Monday, November 19, 2007 5:08 PM
>>> To: persistence_at_glassfish.dev.java.net
>>> Subject: Re: Configuration of Client vs. Shared Cache
>>>
>>>
>>> Hello Gordon,
>>>
>>> thank you for the fast answer.
>>> Gordon Yorke schrieb:
>>>
>>>> Hello Adam,
>>>> An application managed EntityManager always wraps an Extended
>>>> Persistence Context. An Extended Persistence Context is not
>>>> released until the EntityManager is closed unlike a transactional
>>>> Container Managed Entity Manager which releases the Persistence
>>>> Context at the end of each transaction.
>>>>
>>>> If you need you can simulate the transactional EntityManager by
>>>> calling flush(), clear() before each commit() but this would still
>>>> leave you with the detached issue.
>>>>
>>>>
>>> This is our issue. Detached entities are a real problem in more complex
>>> applications...
>>>
>>>> The problem with holding the objects in a weak reference is the
>>>> change detection requirement of the PersistenceContext. Any object
>>>> touched by the PersistenceContext must be tracked by the
>>>> PersistenceContext and any changes to that object must be written
>>>> to the database on request, even if the object is no longer
>>>> referenced by the application. With weak references unwritten
>>>> changes could potentially be lost.
>>>>
>>>>
>>> "even if the object is no longer referenced by the application" -> why
>>> this? In case an object isn't referenced by the application any
>>> more, it
>>> could simply disappear... Especially in an unmanaged environment. This
>>> extension would be really valuable for rich clients ("rias"). Actually
>>> this problem will have every rich client application. How hard would it
>>> be to provide a switch to be able to choose between hard and weak
>>> references?
>>>
>>>> There a multiple ways you could manage the volume of object
>>>> registered within a Persistence Context. On screen changes you
>>>> could close and create a new EntityManager but my recomended
>>>> approach would be to detach the display objects from the managed
>>>> objects. No need to create seperate classes but you could use the
>>>> merge facility of the EntityManager to merge the objects from the
>>>> GUI to the PersistenceContext for any object updates or specific
>>>> save events from the GUI.
>>>>
>>> The problem here: the object graph is really complicated with recursive
>>> algorithms (about 700 entities...). Therefore we would rely on
>>> "transparent persistence". Actually it works great with TopLink on
>>> Smalltalk :-). We have only the issue in Java... However TopLink is the
>>> only OR-framework, which can handle this complexity. The only issue are
>>> the "hard" references.
>>>
>>>
>>>> This would limit the number of objects in your PersistenceContext
>>>> and mostlikly provide for a performance improvement from your
>>>> current design as less objects are being checked for changes. I
>>>> would also recommend that if you took this approach that you switch
>>>> the shared cache to be a softcache weak identity map.
>>>>
>>>>
>>> We switched the shared cache already. The L1-cache is our problem...
>>>
>>> thank you for the detailed answer,
>>>
>>> adam
>>>
>>>> --Gordon
>>>>
>>>> -----Original Message-----
>>>> From: Adam Bien [mailto:abien_at_adam-bien.com]
>>>> Sent: Monday, November 19, 2007 11:46 AM
>>>> To: gordon.yorke_at_oracle.com
>>>> Cc: persistence_at_glassfish.dev.java.net
>>>> Subject: Re: Configuration of Client vs. Shared Cache
>>>>
>>>>
>>>> Hi Gordon,
>>>>
>>>> thank you very much for the fast reply. I'm thinking of the
>>>> Persistence
>>>> Context as an Identity HashMap, which primary goal is to keep the
>>>> consistency of the entities in a transaction.
>>>> However in our application (it is a rich client, which connects
>>>> directly
>>>> to the database without an application server or middleware), it seems
>>>> like once loaded objects are hold
>>>> by the EntityManager until the method clear is invoked or the Entity
>>>> Manager is closed (we are using the current build - TopLink
>>>> v2b58). The
>>>> Entity Manager remains open between the transactions - it is even not
>>>> cleared. We would like to work with the entities, without loading them
>>>> from the database every time.
>>>>
>>>> We are using data binding between the domain objects and the UI - so
>>>> clearing the entity manager makes the entities detached (and makes the
>>>> GC run) - the whole app has to be refreshed then. This in turn is not
>>>> wished by the end users :-).
>>>>
>>>> I'm wondering, whether it would be possible to hold the objects using
>>>> weak-reference in the L1 cache / transactional cache. Then all
>>>> unneeded
>>>> objects would be automatically garbage collected. The object-identity
>>>> would be still provided with this setting... Now the memory
>>>> consumption
>>>> increases - until Out Of Memory occurs...
>>>>
>>>> any thoughts?
>>>>
>>>> thank you in advance,
>>>>
>>>>
>>>> regards,
>>>>
>>>> adam
>>>>
>>>>
>>>>
>>>> Gordon Yorke schrieb:
>>>>
>>>>
>>>>> Hello Adam,
>>>>> You may be confusing the Persistence Context with a cache?
>>>>> Sometimes the UnitOfWork which is the implementation of the
>>>>> Persistence Context in TopLink is described as a cache to explain
>>>>> some
>>>>> of its behaviours but its behaviour is beyond that of a cache.
>>>>> Because the Unit0fWork must track all objects that were ever read
>>>>> through or registered by the UnitOfWork to full its behavioural
>>>>> requirements the TopLink cache settings do not apply.
>>>>> --Gordon
>>>>>
>>>>>
>>>>> Adam Bien wrote:
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> TopLink cache consists of two parts:
>>>>>> 1. Client/L1
>>>>>> 2. Shared/L2
>>>>>>
>>>>>> Is it possible to configure them independently? In the TopLink
>>>>>> reference there are two sections:
>>>>>>
>>>>>> http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#BABGDJBC
>>>>>>
>>>>>>
>>>>>>
>>>>>> It seems like the @Cache annotation addresses the Client/L1 cache.
>>>>>> The properties (
>>>>>>
>>>>>> eg. <property name="toplink.cache.type.Order" value="Full"/>) the
>>>>>> L2.
>>>>>>
>>>>>> Is it possible to configure both caches using the persistence.xml
>>>>>> properties?
>>>>>>
>>>>>> I would like to configure Weak Caches for both levels, however it
>>>>>> seems like the L1 cache is still "Full" (or it uses "hard"
>>>>>> references
>>>>>> to entities)
>>>>>>
>>>>>> thank you in advance!,
>>>>>>
>>>>>> adam bien
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Consultant, Author, Java Champion
>>>>
>>>> Homepage: www.adam-bien.com
>>>> Weblog: blog.adam-bien.com
>>>> eMail: abien_at_adam-bien.com
>>>> Mobile: 0049(0)170 280 3144
>>>>
>>>> Books: Enterprise Architekturen (ISBN: 393504299X),
>>>> Java EE 5 Architekturen (ISBN: 3939084247),
>>>> J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Consultant, Author, Java Champion
>>>
>>> Homepage: www.adam-bien.com
>>> Weblog: blog.adam-bien.com
>>> eMail: abien_at_adam-bien.com
>>> Mobile: 0049(0)170 280 3144
>>>
>>> Books: Enterprise Architekturen (ISBN: 393504299X),
>>> Java EE 5 Architekturen (ISBN: 3939084247),
>>> J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts
>>>
>>>
>>>
>>
>>
>
--
Consultant, Author, Java Champion
Homepage: www.adam-bien.com
Weblog: blog.adam-bien.com
eMail: abien_at_adam-bien.com
Mobile: 0049(0)170 280 3144
Books: Enterprise Architekturen (ISBN: 393504299X),
Java EE 5 Architekturen (ISBN: 3939084247),
J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts