We might need to open a feature request to support this.

 

For now, the only workaround I can think of is somewhat complicated - it would involve implementing a custom EntityServerSaveInterceptor and storing its EntityManager (or sufficient information for your pooling logic) in a thread local variable, which you would then use in your IdGenerator.

 

If you don't wish to engage Professional Services, then I would start by changing the Imports statements, and also look at the DF 2010 IIdGenerator interface definition, which does have slight changes.  Your pooling logic should not require changes, other than removing the RdbKey and AdoHelper.   For more information on the IIdGenerator, see http://drc.ideablade.com/xwiki/bin/view/Documentation/create-custom-id-generation.

 

 

The NumericIdGenerator is a sample implementation of the IIdGeneratorInterface, and can be used "as is" or modified to suit your needs.  The sample logic always allocates a whole block of ids to be used globally.  To change this you'll need to modify the GetRealIdMap logic and related code.  From each UniqueId in the collection passed you can obtain the DataEntityProperty and from that the EntityType to discover which entity types need real ids, and modify the allocation logic and SQL queries as needed.

 

In DevForce 2010 we usually find that Guids make better key fields, since once assigned they are permanent and no temporary-to-real id fixup is required.  Database identity columns are another option:  id fixup is required, but DevForce handles all the temporary id allocation and fixup for you.