"Jonathan K. Weedon" wrote:
>
> Gene,
>
> ...
>
> What do we do instead?  We serialize the primary key to a chunk of bytes,
> and then use internal hashCode/equals functions which runs against that
> chunk of bytes.  This is much faster than calling the equals/hashCode
> methods, and results in a truly uniform distribution, resulting in fast
> dictionary lookups, etc.

We do this also, but we sometimes use GIOP 1.1 CDR syntax (encapsulation)
instead of Java serialization. It takes less space and is faster to
compute.

> ...
>
> One last point, on the use of FatKeys.  What would happen if you called the
> multi-object finder in one transaction, and then used the object references
> in another transaction.  Previously, you said that you need to clear out
> the data fields in your ejbLoad method, so that ejbLoad is only called
> once.  This is good.  But what about if ejbLoad is never called in the
> finder's transaction, but only in a subsequent transaction.  Here, you would
> still be loading the (potentially obsolete) state.  Sound like the design
> pattern is still broken, but for different reasons.

There are two possible ways of dealing with this:

(1) Put a timestamp (e.g. System.currentTimeMillis()) into your fat keys, so
    you can detect stale data based on timeouts (for read-only transactions).

(2) Use optimistic updates to avoid the possibility of updating the database
    based on stale data that was read from a FatKey.

I think in the end, Gene's approach is interesting, and although it is arguably
(and perhaps provably) not portable, it would appear to be of considerable
practical use. Once EJB servers have matured to the point that most of them
have powerful caching options (at least for CMP), it would be less interesting.
________________________________________________________________________________

Evan Ireland              Sybase EAServer Engineering        [EMAIL PROTECTED]
                            Wellington, New Zealand               +64 4 934-5856

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to