On Mon, 15 Mar 2010, Mindaugas Kavaliauskas wrote:
Hi,
> I have a related question/problem. Let's say I want to transfer
> areas among threads (that's the purpose of alias detaching). I'm
> missing two functions:
> 1) to attach alias within another thread using a different alias name;
> 2) to search a "zerospace" for a specific area having some dbf file,
> some open mode, index, etc.
> These missing functionality could be reached by function which
> renames current alias. F.e.:
> USE items NEW ORDER number READONLY ALIAS items1
> ....
> HB_DBSETALIAS("items_number_RO")
> HB_DBDETACH()
>
> Another thread:
> HB_DBREQUEST("items_number_RO",,, .T.)
> HB_DBSETALIAS("items_ro")
> ...
> This could be a waste dynsym table if I want add a random HTTP
> session number to a database name before detaching it (let's say I
> want to cache opened tables for HTTP session). It this case I find a
> useful solution to store a required (for reattaching) data in cargo
> field. F.e.:
> USE items NEW ORDER number READONLY ALIAS items1
> ....
> HB_DBDETACH(, "items_" + cSession)
> Another thread:
> HB_DBREQUEST({|alias,cargo| IIF(cargo == "items_" + cSession,
> (alias := "items_ro", .T.), .F.)},,, .T.)
> ...
> /* Here block is a kind of search block. It also assigns a new
> alias name */
> The second proposed solution is more flexible, but is not optimal
> because it keeps a long mutex lock on "zerospace" internals.
Just like WorkaAreaEval() in xbase++ and it's the reason why I still
haven't added it to SVN code.
There is one very serious problem with alias name modification and
switching workareas between threads. It hardly interacts with RDDs
using remote servers which allows to optimize expressions and execute
them on the server side. It causes that it's necessary to replicate
on the server side all local alias modifications what can seriously
reduce the performance.
Anyhow current code which tries to follow xbase++ specification
replicated also some xbase++ anomalies (fortunately not all) so it
has to be cleaned and I plan to make.
Your propositions are very interesting but before I'll change anything
in this code I will want to rethink all interactions with RDDs using
remote servers.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
