persistence@glassfish.java.net

RE: Idea for optimistic concurrency extension

From: Peter Krogh <peter.krogh_at_oracle.com>
Date: Thu, 10 Aug 2006 21:21:54 -0400

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.

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?

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> 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
    Homepage: www.adam-bien.com
    Weblog: 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