Peter,
> Hi all,
>
> This feature is one of many features that go beyond the spec that
> should be considered for future inclusion in the product. We welcome
> community involvement in all phases of the feature development cycle.
How can this happen. Can we just commit the code? :-)
>
> This may be a good time to start the general discussion of configuring
> and supporting things beyond the spec. Anyone have any thoughts on
> how they would like to see advanced configuration (config beyond the
> spec) handled?
Custom annotations: org.glassfish etc. and XML could do the job. I'd
prefer annotations, because then the dependency to Glassfish is more
obvious. In case someone would like to migrate,
the affected areas are more easily to identifiy. DD configuration should
be of course also possible.
I will post my next ideas from time to time here :-).
>
> Thanks,
> Peter
>
>
> -----Original Message-----
> *From:* Wonseok Kim [mailto:guruwons_at_gmail.com]
> *Sent:* Wednesday, August 09, 2006 11:37 PM
> *To:* persistence_at_glassfish.dev.java.net
> *Subject:* Re: Idea for optimistic concurrency extension
>
> Hi, Adam
>
> As I know TopLink Essentials has limited optimistic locking
> feature - only version locking policy.
> But TopLink itself has several other optimistic locking features -
> field-based locking policy(all fields, changed fields or selected
> fields).
> See
> http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/descfg025.htm
>
> I wonder that these extended features can be ported to TopLink
> Essentials.
> If Oracle is reluctant to do this due to its policy, other
> developers may be able to do this by its own implementation.
>
> I don't know what is Oracle or Sun's policy about those kinds of
> extended features.
> Will the extended features of TopLink be migrated gradually to
> TopLink Essentials? Or should GlassFish itself implement its own
> implementation for those features? Or GlassFish won't do anything
> about this, so users should implement those for themselves?
>
> -Wonseok
>
> On 8/9/06, *Adam Bien* <abien_at_adam-bien.com
> <mailto:abien_at_adam-bien.com>> wrote:
>
> I discussed the following idea already with craig at the JAOO
> 2005.
>
> Problem:
>
> If you detach a persistent entity send it to client, then
> back, the
> "before image" is lost.
> In this case you need a version number or timestamp. You can
> have a
> problem, in case you are working with a legacy database - it
> is often
> hard or not allowed to change the schema.
>
> Now the following idea: why not send the before image together
> with the
> entity?
> As a improvement also only the where statement could be sent
> over the
> wire. This should be sufficient to detect the collisions,
>
> I'm not sure, whether this list is the right place to discuss
> the things
> - but I think such a feature would be unique...
>
> greetings,
>
> adam
>
> --
> Dipl. Inf. adam bien
>
> BEA Technical Director
> Sun Certified Java Programmer
> Sun Certified Enterprise Java Architect
> Sun Enterprise Java Trainer
>
> Mobile: 0049(0)170 280 3144
> eMail: abien_at_adam-bien.com <mailto:abien_at_adam-bien.com>
> Homepage: www.adam-bien.com <http://www.adam-bien.com>
> Weblog: http://www.adam-bien.com/roller/page/abien
> <http://www.adam-bien.com/roller/page/abien>
> ----------
> Book author:
>
> Enterprise Architekturen
> entwickler.press 2006
> ISBN: 393504299X
>
> and Enterprise Java Frameworks,
> J2EE Patterns, J2EE HotSpots and Struts.
>
>
>
>
> --
> Wonseok Kim
> Senior Developer, TmaxSoft
>