Peter Liu wrote:
>> I don't think so IIUC, as the transaction is only scoped for the
>> method call and not over multiple requests/responses. It is a bit like
>> calling the start transaction before you call the method and the
>> commit transaction (or rollback on error) after the call.
>>
>> Paul.
>>
> Any idea when the things we discussed here may become reality? Also,
> perhaps support for some form of memory caching can be part of this?
>
Not sure, i think it depends on the availability of a WebBeans
implementations.
In terms of caching, say using something like memcached, i think there
are a number of intertwining things that need to be separated out into
their connecting areas of the RESTful framework, DB framework and
tooling for development and deployment.
Just like NetBeans manages a database it would make sense for it to
manage a memcached instance.
From a development perspective the application should not care if
memcached is used or not (namely it should work if it is not enabled).
This makes me think that memcached should be part of a JPA
implementation or there should be a general CRUD library that
encapsulates memcached support i.e. it is not something that is specific
to REST per say (just like the transaction stuff, which is why i would
like to depend on something like WebBeans rather than implement that
stuff myself).
To be honest i lack the expertise in this area and i think DB and
tooling heads need to get together to scope something out around such
caching support.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109