Sounds like good advice. We will start with a fresh DataContext for each
request.
When I worked with CORBA we used IDL to define our interfaces, Web Services
use WSDL (basically an XML based version of IDL). In order to use the Web
Services across platforms it is necessary to only pass Beans or primitive
data types across the wire.
It doesn't look like it is possible to pass DataObjects around unless there
is some type of custom serializer/deserializer available. In lieu of not
being able to use DataObjects we will need to be able to create Beans for
each of the DataObjects that we can then pass around.
Relationships are kind of tricky, but from my CORBA experience it is very
desireable to create separate methods to get the relationship data otherwise
the interface and marshalling of objects is very inefficient.
Question:
1. Is there a way to generate the bean classes from the Cayenne modeler?
2. Is there a way to populate the bean classes from the Cayenne framework?
Ideally the modeler could also generate a set of plain old Java beans that
could be used in the framework so that they could be populated and
maintained automatically.
Thanks in advance
On 1/10/06 10:47 PM, "Andrus Adamchik" <andru..bjectstyle.org> wrote:
>>> What about the difference between Thread bound datacontext and
>>> session bound
>>> data context? Which would be more appropriate for a stateless web
>>> service
>
> In a webapp scenario session DataContext is repeatedly bound to a
> request thread, so both patterns are at work at the same time.
>
>
> On Jan 10, 2006, at 10:35 PM, Cris Daniluk wrote:
>
>> Now, if its truely stateless - where each request can be assumed to
>> have little in common with the previous, then I would personally think
>> creating a new DataContext for each request is the way to go. Since
>> the DataContexts aren't really threadsafe anyway, it probably doesn't
>> make sense to do it any other way.
>
> To add to that... If there are no real sessions (i.e. no state stored
> between requests), you can create a pool of DataContexts and randomly
> bind context instances to threads (making sure you rollback any
> changes at the end of request cycle). Under some circumstances you
> may get extra performance benefits from ObjectStore caching ... But I
> would think that generally any such benefit would be negligible. So I
> second Cris's advice - you are better off creating a fresh DC on
> every request. Only consider the pool solution if you have profiling
> data that proves otherwise.
>
> Andrus
>
This archive was generated by hypermail 2.0.0 : Tue Jan 10 2006 - 23:07:35 EST