Evan Ireland wrote:
>
> "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.
Actually, we do this too, for exactly the same reason. By "serialize" I
did not mean we use Java Serialization, which as you point out is quite
inefficient. We use GIOP serialization instead.
> > ...
> >
> > 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).
I don't see how a timeout helps. System time is measured in milliseconds. It
is very much possible for my evil case (get the obj ref in one transaction, use
it in another) could all perform within a millisecond. So, I don't think timeouts
fix the problem, although they do make it less frequent, perhaps.
> (2) Use optimistic updates to avoid the possibility of updating the database
> based on stale data that was read from a FatKey.
This absolutely would work. In particular, since IAS supports this type of
update (updates which verify the loaded state from the beginning of the
transaction, or from the FatKey, in this case) this would be a useful workaround.
Unfortunately, verfied updates are not a standard feature.
> 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.
I very much agree that all this extra (incorrect, non-portable, application-
specific, vendor-specific) code used to workaround the limitations of BMP is
a bit crazy. Better to use a more powerful CMP engine, and write simple CMP
code, IMO.
> ________________________________________________________________________________
>
> 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".
===========================================================================
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".
